Defining MIDI Channel of Incoming Notes: How??

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
Post Reply
User avatar
Raveshaper
Posts: 1089
Joined: 16 Jan 2015

08 May 2015

I have tried literally everything I can think of with no success, and I'll risk asking this here as my last resort.

Is there a parameter I can use to define the midi channel of a note coming in using remote.handle_input()?
"Value" doesn't do this, "note" obviously doesn't do this, "channel" doesn't do this and "port" doesn't do this. So is there some optional parameter I don't know about? I'm desperate at this point.

I would like direct input of notes in the equivalent of the format "9? yy zz" without being forced to loop back (because looping back is absurd in this case). No pad bank/drum controller codecs I have seen do anything like this, which makes me fear it isn't possible at all.

PM replies are fine if you don't want to discuss this on the board.
:reason: :ignition: :re: :refillpacker: Enhanced by DataBridge v5

User avatar
Benedict
Competition Winner
Posts: 2747
Joined: 16 Jan 2015
Location: Gold Coast, Australia
Contact:

08 May 2015

I think you just need to be using Advanced MIDI routing up there on the IO section

:)
Benedict Roff-Marsh
Completely burned and gone

User avatar
Raveshaper
Posts: 1089
Joined: 16 Jan 2015

08 May 2015

I tried that. I even defined an old school midi codec to funnel notes to specific channels, then locked them to separate devices in hopes the notes would distribute to the right destinations.
No dice.

In a previous incarnation of this project, the old school codecs worked perfectly for this and worked as described above -- notes went to the appropriate device according to surface locks.
But this method won't help me now.

The MIDI Bus in the advanced routing section recognizes the midi events because the appropriate channel activity indicators light up on the routing channels.
But the notes themselves only recognize the device on the sequencer track that is currently selected.
I need as many as all 16 midi channels driving 16 separate devices simultaneously regardless of selected sequencer tracks.

handle_input() should be able to, pun alert: handle this.

All joking aside, this probably comes down to the map file's binding to the master keyboard.
I can't map multiple surface controls to it because it throws an error.
I have to direct notes by mapping to the master keyboard or nothing plays at all.

As usual, this isn't a simple project.
What I have built is a virtual pad page system that uses the stepped jog wheel of my controller to select the root of the 16 note chunk or "octave" that I want to play on my 4 x 4 pads.
Hardware configuration separate from Reason defines each physical page of pads with its own midi channel from 1 to 8.
On hardware pad page 1, I can freely play notes up and down all 128 values by simply jamming on the pads and twisting the jog wheel.
Notes that are held while changing base octave overlap on top of newly triggered notes so that sounds can overlap if desired.
Because the note values must be calculated based on changes in the state of my jog wheel, they can not be hard-coded in advance.
Also, and more important, I must use MIDI CC values and then interpret those to send in the variable notes, because defining pads to send notes will only send those predefined notes.

Playback of a device only happens when the device is selected in the arrangement window and the midi channel is 1.
Also no notes pass unless "value" inside of handle_input() is equal to 1.
That thing about value=1 doesn't matter, unless value must equal something particular in order to steer the midi channel.
What I need is to be able to freely jam on multiple midi channels as defined by the selected hardware pad page.
:reason: :ignition: :re: :refillpacker: Enhanced by DataBridge v5

User avatar
Raveshaper
Posts: 1089
Joined: 16 Jan 2015

09 May 2015

After a million years of debugging, I have determined the following:

event[1] is the midi channel in terms of CC (140-155)
event[2] is the midi CC or note (0-127)
event[3] is the midi value or velocity (0-127)

ret.x = midi channel number (0 to 15, decimal)
ret.y = midi CC/note number (0 to 127, decimal)
ret.z = midi value/velocity (0 to 127, decimal)

I patched in a deliver_midi handler to see if the ugly option would suffice, and it created two problems.
1 - it would not play pad 7 except on the moment of release, all others were fine
2 - it introduced analog latency because of loopback

I switched back to the first arrangement, redacted the deliver_midi so it wouldn't execute and pad 7 worked fine again.
Still strangled to midi channel 1 only. I literally do not understand that.
The device is bound in the MIDI Bus.
The indicator lights up for each channel.
Notes work fine on channel 1.
Anywhere else, no sound comes out.

If this is some kind of private joke, I'm not laughing. I've sunk two days into this when the code should operate as expected after a few minutes of writing and testing. Wouldn't be the first time someone found something deeply broken in the program and I really hope I'm not being cynical in saying that.
:reason: :ignition: :re: :refillpacker: Enhanced by DataBridge v5

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 26 guests