[sdiy] Anyone know of a device that does no-added-delay MIDI filtering?

[Bob Weigel]

Yes I'm aware of the hardward details there... But  I'm talking about 
eliminating latency for both FRESH note messages (ie. ones that aren't 
on running status currently.  This would be any information being 
generated on a fresh channel of course) AND FRESH controllers.   It's a 
minor improvement like I said.  Just a nit-picky thing that could be 
done on certain older synths and now that I realize my P600 keeps 
responding to everything and just reassigning it to the previous octave 
as it goes down...I probably won't even bother.

It was a good puzzle to think about though and it will work on some 
units.  Just not all of them which is a bummer but oh well.  -Bob

Colin f wrote:

>Bob, 
>
>  
>
>>1) all incoming status bytes go through all ports that are set up for 
>>*this* type of filtering (was thinking of an option switch to 
>>turn it on 
>>to standard buffer before send in case a machine like P600 isn't 
>>compatable with the scheme). 
>>
>>2) If the CPU sees that a status byte is not intended for a 
>>machine it 
>>was just sent to, it doesn't send the following 2 bytes for a note 
>>message.  Rather it subsitutes NOTE 0...or NOT 127...neither of which 
>>will trigger many old synths I believe :-).  I at least have 
>>some that 
>>don't respond including the Siel as I recall.   Then selects zero for 
>>velocity probably.
>>
>>If it's a controller message, and it's not for this synth, then the 
>>value to follow is substituted for the 'last value' saved in memory.
>>
>>Cool?
>>    
>>
>
>My understanding of the original problem was that you want a filter device
>that receives a single MIDI stream.
>This device has multiple outputs, each of which only pass MIDI data for a
>specific MIDI channel, so omni receiving synths will only receive messages
>on the channel you want to use them on.
>
>If you have a CPU multiple hardware UARTS this is dead easy.
>You have a status flag for each output, to say that the current running
>status matches that output's filter channel.
>These statuses are all set off at boot.
>When you receive a status byte at the input, you compare it to the filter
>channel for each output, and activate that output if it matches. You then
>immediately pass the status byte on active outputs.
>When you receive data bytes, you pass them to any active outputs too.
>You could have a different rule for each type of status byte for each output
>if required, for example to decide whether system common and realtime pass
>to the filtered outputs.
>Even if you don't have hardware outputs, it's relatively easy to write a
>timer driven software UART, so you are only limited to the number of output
>pins on your PIC etc. for the number of output channels you want.
>
>Cheers,
>Colin f
>
>
>
>  
>