DSP Robotics Support

Hi,

I have a question about passing through specific midi events by their midi channel number. For instance, Lets say we are running a packed midi sequence which contains midi data from channel 1, 2,3,4 and 5 into a single midi input. Is there a way (probably with Ruby) to pass through only channel 3 while ignoring 1,2,4 and 5? AFAIK, no green primitive can do it.

Every midi message contains the channel number it belongs to. Pass only those with the correct channel number. Can be done with green and Ruby.

Green is less relevant, since it can not be bounced in the DAW due to an old bug. Is there any simple Ruby code line the filters a selected channel? I tried this one (@channel refers to an external integer input that determines the selected channel number)

Code: Select all

def event i,v
  m = @midiInput.to_array
  output Midi.new m[0],@channel,m[2],m[3]
 
  end


This code is not filtering, but just sends out the whole midi pack through the determined channel instead.

Try this:

output Midi.new m[0],m[1],m[2],m[3] if m[1] == @channel

Should work

DaveyBoy wrote:Try this:

output Midi.new m[0],m[1],m[2],m[3] if m[1] == @channel

Should work

Thanks very much, Daveyboy. It works

Just a general knowledge question:
What your code actually says is kinda "listen to the midi sequence and open the gate whenever a note with the correct midi channel arrives".
I'm just wondering if the midi protocol sends through the midi data organized into channels while every channel gets it's own private "pipe" or it's just a wild geyser of un-organized data that we should organize into channels after we receive it. If the first option is the correct one, maybe we can write something more effective that says "leave channel 3's pipe open and close all the others".

Wild geyser is a good description! MIDI is a Wild Geezer, I've always thought so.

MIDI is a relatively slow communication system, and just sends one intruction after another. Some have specific MIDI-channel numbers included, others do not. 'Notes' , 'Controllers' & ' Program Changes' do, but other things like Sysex, sequencer start-stop, PRNs & NPRNs (non-registered parameter numbers) do not. So there's certainly no 'channel pipe'.

One thing that was quickly added to the original 1980's protocol was 'Running Status', to speed things up a bit. Normally a 'Status Byte' is sent at the start of each instruction, so as you know a MIDI-Note goes : status, channel, note-number, velocity; however Running Status just sends the status byte once, and then everything following is assumed to be the same (e.g. notes, which is the ususal case), until told otherwise by a new substitute Status Byte. Flowstone already takes care of this.

Another speed-up strategy was to send Note-Off as 'Note-On with zero velocity', which under running-status also saves having to send yet another different Status Byte every time a key's released.

I dare say if MIDI was being designed in 2021 it would look a little different, but hey, they'd be no Flowstone until 2022!! What the hell would we all do?

H

Great comment, Hugh. Thank you for the light shedding. Still waiting for midi 2.0 to become an industry standard and things then would become lot more interesting. I'm also wanna believe that this time data would become organized into dedicated "pipes" and the resolution would go up to float grade instead of just the poor 127 steps integer grade. This way, you would be able, for instance, to edit microtuner cents straight from the midi stage and not just semitones.

I'm following the midi association site and the new 2.0 standard seems pretty promising. I'm so waiting for this. More info here:

https://www.youtube.com/watch?v=klun6WMxryU&feature=emb_logo

HughBanton wrote:
One thing that was quickly added to the original 1980's protocol was 'Running Status', to speed things up a bit. Normally a 'Status Byte' is sent at the start of each instruction, so as you know a MIDI-Note goes : status, channel, note-number, velocity; however Running Status just sends the status byte once, and then everything following is assumed to be the same (e.g. notes, which is the ususal case), until told otherwise by a new substitute Status Byte. Flowstone already takes care of this.

Another speed-up strategy was to send Note-Off as 'Note-On with zero velocity', which under running-status also saves having to send yet another different Status Byte every time a key's released.

It’s worth adding that whilst FlowStone handles it in the MIDI to Voices system, if we make any MIDI processing ourselves we have to make provision for running status ourselves. If we don’t then homemade on-screen keyboards will never release their notes and arpeggiators will never stop etc.

My previous keyboard was by M-Audio and it used running status, as I think theirs all do. But my new Novation Impulse 61 doesn’t do it. This meant that I had to find a midi file (attached) which used running status to test my Ruby code. You can use this midi file for testing your own code.

An alternative is to use the attached module which converts any Note on vel =0 to a Note off message and passes everything else through unaltered.

Spogg wrote:An alternative is to use the attached module which converts any Note on vel =0 to a Note off message and passes everything else through unaltered.

This green midi solution will cause bouncing problems in the D.A.W (an old bug). Here is the Ruby version of it which doesn't disrupt midi process after exporting the dll.

Thanks for the Ruby version!

I wonder could you explain exactly what you mean by "bouncing problems"?

In the old days bouncing meant mixing an existing track with incoming audio and recording this mix on a new track. That was when tape tracks were limited. So with unlimited DAW tracks available these days, I suspect it means something different...

Cheers!