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

[Fredrik Carlqvist]

It would be possible to make a no latency filter by "disarming" messages for a non-wanted channel. 

The midi input goes through a multiplexer under micro control to the midi output. Normally, the multiplexer selects the midi in, so messages go right through, but the usart output of the micro goes into the other input of the mux. The micro also listens to the conversation. 

When a status byte of a channel to be filtered arrives, the microcontroller selects the alternate mux channel, replacing the original data bytes. For example, for a note on, the microcontroller replaces the data bytes by 00 00, being careful not to mask any realtime messages. This would be interpreted as a note off for note 0 by the receiving instrument - thus not triggering a note on. Since there will be a corresponding note off, masked in a similar way, all noteon messages for note #0 will be turned off eventually.

All possible status bytes with a channel number in them needs a dummy data, a controller message could go to an unimplemented control number such as 119, an aftertouch message could send to note #0 (unlikely to be implemented) etc.

Actually, as someone pointed out - the data direction is little endian - lsb first. And the channel number is in the low nibble, so it might be possible to properly filter out status bytes as well, but only directly in hardware, not using a usart. However, realtime and common messages would be filtered out as well. There is no way of telling if it is a midi clock message or a note on for midi channel 9 just looking at the first four bits to arrive.


Fredrik C


-----Original Message-----
From: owner-synth-diy at dropmix.xs4all.nl [mailto:owner-synth-diy at dropmix.xs4all.nl] On Behalf Of Bob Weigel
Sent: den 7 mars 2006 00:30
To: ASSI
Cc: synth-diy at dropmix.xs4all.nl
Subject: Re: [sdiy] Anyone know of a device that does no-added-delay MIDI filtering?

Hmm.  Ohhhh I see what you're saying I think.  This is another question I'd have to write a file with the data and just send it out my midi data transmitter from spg to test.  Some old synths *may* be expecting to see the data after a note on for instance.  Otherwise they may hang. 

So you are suggesting rather than sending data to just skip it and send another staus byte instead?  Hmm.  Well if the machine were already on running status with notes on the channel it's *supposed* to be responding to, then we wouldn't want to do that now would we?

See..say we had another channels' controller message come in in the middle of a chord for instance that was being played on the channelized 
machine.   You'd either have to complete the message by sending the 
previous stored controller value for that machine on the channelized port.. or do what I think you are suggesting and instead just send another Note on message on the channelized port.  And that might work and save a byte here and there in the process. (Or..I should say send the last 'potentially running' status byte again.) 

I just am not sure if that will work on some of the clunky old firmware.  Good idea though and I'll try it if I ever get around to doing this. -Bob

ASSI wrote:

>On Montag, 6. März 2006 01:07, Bob Weigel wrote:
>  
>
>>I'm not sure what you mean below.  To 'switch status' requires...a 
>>status byte.  Is that what you are calling an 'intervening message'?
>>    
>>
>
>You send one status byte and you'd normally send the corresponding 
>message, a Note On event for instance (consisting of note number and 
>velocity). Instead you could chose to send a different status byte (for 
>a Control Change perhaps) directly.
>
>
>Achim.
>  
>