Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Filtering a specific midi channel from a packed midi event

For general discussion related FlowStone

Filtering a specific midi channel from a packed midi event

Postby kortezzzz » Sat Feb 20, 2021 9:30 am

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.
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: Filtering a specific midi channel from a packed midi eve

Postby tulamide » Sat Feb 20, 2021 11:30 am

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.
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Filtering a specific midi channel from a packed midi eve

Postby kortezzzz » Sat Feb 20, 2021 11:56 am

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.
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: Filtering a specific midi channel from a packed midi eve

Postby DaveyBoy » Sat Feb 20, 2021 8:45 pm

Try this:

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

Should work :D
User avatar
DaveyBoy
 
Posts: 131
Joined: Wed May 11, 2016 9:18 pm
Location: Leeds UK

Re: Filtering a specific midi channel from a packed midi eve

Postby kortezzzz » Sat Feb 20, 2021 10:21 pm

DaveyBoy wrote:Try this:

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

Should work :D


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".
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: Filtering a specific midi channel from a packed midi eve

Postby HughBanton » Sun Feb 21, 2021 9:18 pm

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? :lol:

H
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Re: Filtering a specific midi channel from a packed midi eve

Postby kortezzzz » Mon Feb 22, 2021 12:19 am

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
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: Filtering a specific midi channel from a packed midi eve

Postby Spogg » Mon Feb 22, 2021 8:36 am

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.
Attachments
801_Tripping_up_the_Stairs NOTE OFF = VEL 0__.zip
Midi file with Running Status
(502 Bytes) Downloaded 782 times
Midi running status.fsm
FS 3.06
(582 Bytes) Downloaded 784 times
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Filtering a specific midi channel from a packed midi eve

Postby kortezzzz » Mon Feb 22, 2021 1:26 pm

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.
Attachments
(Midi running status Ruby).fsm
(386 Bytes) Downloaded 789 times
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: Filtering a specific midi channel from a packed midi eve

Postby Spogg » Tue Feb 23, 2021 8:30 am

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!
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Next

Return to General

Who is online

Users browsing this forum: No registered users and 44 guests