not really sure if this is the right place, but here goes.
i'm running into a few problems with the midi control on some rack gear.
i'm using a dmc ground control pro to control my rack, but the unit thats causing me the problem is a boss gx700.
whats happening is when using an expression pedal with the GCPro, its putting out too much CC data and the midi buffer on the gx700 cant cope.
i never had this problem with the old style ground control and after looking at the CC data the old and new units put out i can see why. the new GCPro sends out about 3 times as much data over the same time period as the old one did.
this doesnt cause a problem with the rest of my gear, just the boss.
so i'm left looking for a solution really. i know the obvious one would be to either stop using the gx700 or go back to the old GC. really though, i dont want to do either.
does anyone know of a unit that basically reduces the amount of midi data or reduces the resolution of the midi flow?
i'm stumped.
How bout a MIDI channel filter??
This allows only ONE channel to come thru.
This would escentially filter out ALL other channels, considerablly reducing the data stream.
Here's a DIY version ---
http://tomscarff.tripod.com/midi_chan_filt/midi_channel_filter.htm
afn
T
thanks for the reply.
i'm not using the devices in omni mode, the problem rack (along with my other rack gear) is on its own midi channel.
theres just too much CC data. just wish there was something to remove every other CC value.
its a ...unique problem (read as - its doing my f**king head in)
cheers
Are those CCs used to control some effects in GX700? Or maybe they are used to control other device, but GX700 is also receiving them and that causes malfunctions?
A device that splits the midi signal in two paths (one for GX700, second for the rest) and cuts out all the CC commands in one path is not so difficult to design. All you need is some microcontroller with Serial Interface (UART), some programming skills and understanding of the Midi protocol.
Going further. I'd see that as a box, let's say "CC Stopper", with features like:
- Midi Channel setting - sets the midi channel of the CC commands to be cut out,
- Controller # setting - sets the controller number that should be cut out from the transmission
If the too fast CC transmission is only problem when the expression pedal is used it's also possible to design a "transmission slower". Something that detects the CC stream, put them in a bigger buffer and spits them out a little bit slower, so the gx700 can recognize and execute all of them.
Unique problem requires unique measures :) but it's all doable
Regards
Piotr
Quote from: free electron on October 27, 2007, 07:03:47 AM
If the too fast CC transmission is only problem when the expression pedal is used it's also possible to design a "transmission slower". Something that detects the CC stream, put them in a bigger buffer and spits them out a little bit slower, so the gx700 can recognize and execute all of them.
Unique problem requires unique measures :) but it's all doable
Regards
Piotr
that sounds like the kind of thing. any ideas how i'd go about making one of these? or any recommended reading on the subject?
cheers
mark
This page (http://www.serasidis.gr/circuits/MidiGenerator/MidiGenerator.htm) has some good info to get you started, though you'll want to use a crystal in place of the built-in clock. His circuit worked for me, but once I got into more complicated transmissions, the internal clock wasn't accurate enough. There are ways around that, but it's much easier to simply use a crystal in the first place.
Also, his project emulates a UART. Once you get your feet wet, it's easier to simply use the UART you already paid for. :icon_smile:
Finally, since I use a Dragon to debug with, I switched to the Tiny2313 in place of the Tiny26. The '2313 has debugWire capabilities, the '26 doesn't.
Quote from: dmk on October 29, 2007, 09:57:11 AM
that sounds like the kind of thing. any ideas how i'd go about making one of these? or any recommended reading on the subject?
There's a good article on www.avrfreaks.net called "MIDI and the AVR".
QuoteThere's a good article on www.avrfreaks.net called "MIDI and the AVR".
Has anyone seen the source code on that one? I remember looking for it a long time ago and all I could locate was the PDF.
Quote from: Dave_B on October 29, 2007, 01:39:24 PM
Has anyone seen the source code on that one? I remember looking for it a long time ago and all I could locate was the PDF.
Some years ago i downloaded the html version of the article and the source code. The link goes 404 now, so if anyone wants it pm me.
Quote from: Dave_B on October 29, 2007, 12:32:06 PM
Finally, since I use a Dragon to debug with, I switched to the Tiny2313 in place of the Tiny26. The '2313 has debugWire capabilities, the '26 doesn't.
See if you can get your hands on the new Tiny261/461/861. They are the upgrade to the Tiny26 and have debugWire.
Andrew
Quote from: The Tone God on October 29, 2007, 03:28:11 PM
Quote from: Dave_B on October 29, 2007, 12:32:06 PM
Finally, since I use a Dragon to debug with, I switched to the Tiny2313 in place of the Tiny26. The '2313 has debugWire capabilities, the '26 doesn't.
See if you can get your hands on the new Tiny261/461/861. They are the upgrade to the Tiny26 and have debugWire.
That's a good suggestion, thanks. I've grown accustomed to the 2313 but even with carefully coded assembler (as careful as I'm capable of) I can chew through 98% of the program memory.
The 2/4/8 in the Tiny*61 name is the memory size so you can scale as needed.
Andrew
Quote from: The Tone God on October 29, 2007, 06:54:08 PM
The 2/4/8 in the Tiny*61 name is the memory size so you can scale as needed.
Andrew
Right, I was (unclearly) acknowledging that. :icon_wink:
Quote from: The Tone God on October 29, 2007, 03:28:11 PM
Quote from: Dave_B on October 29, 2007, 12:32:06 PM
Finally, since I use a Dragon to debug with, I switched to the Tiny2313 in place of the Tiny26. The '2313 has debugWire capabilities, the '26 doesn't.
See if you can get your hands on the new Tiny261/461/861. They are the upgrade to the Tiny26 and have debugWire.
Andrew
On the other hand, after looking at them, those don't have a UART. After thinking about it a while, I now remember that I chose the tiny2313 because it was the only TinyAVR with a UART. I didn't need the capabilities of the Mega chip at the time.
Regarding the original post, it should be easy enough to code a one-purpose box that strips out excess data. All it has to do is look at the incoming data and ignore specific message types, passing everything else. ASMOP as someone here might say. ;D
DMK, have you done this sort of thing before? If yes, were you using assembler or C?
The lack of UART in the Tinys is gripe many have. I personally use the Mega*8 series and scale down from there after development. Rumour has is the Tiny*8 series coming may have UART.
Back to your regularly scheduled thread.
Andrew
If you run the midi through max, there is an object which limits how many messages go through per second - can't rememnber the name of the object but it'l be in the tutorial pdf's.
If you run the midi through max (as in max/msp - or pd/pure data which is the open source version), there is an object which limits how many messages go through per second - can't rememnber the name of the object but it'l be in the tutorial pdf's.