Referring to the quote below from the manual, I don’t understand why anyone would want to do this. If I was transforming a note into a cc, I would just want to choose the type of command to be transformed into, and set a range map or direct mapping of note to command value.
I don’t understand what the channel has to do with the mapping process, other than just be a chosen channel to receive and send.
Thank you for any and all clarification!
Peter
“For example, if you transform a Note On into a CC and assign the CC’s value to be set according to the Note On Channel number (‘Set Value to’ selector set to ‘Incoming Ch.’), then when incoming notes’ channels equal 1, 2, 3, 15 and 16, you’ll see the CC values 0, 8, 16, 112 and 120, respectively. When Transform is set up to do the opposite - use the incoming CC’s Value byte for the Channel number selector, you will see the inverse - CC values 0, 8, 16, 112 and 120 would produce Channel numbers 1, 2, 3, 15 and 16, respectively.”
The example’s wording is merely to show the arithmetic one does when converting the values for 16 channels ↔ 128 values/velocities/CCids/note#s
Using the channel information to create the other message information isn’t something one often wants or needs to do, but there are occasions when not having that capability either prevents a solution or makes it verbose.
Take, for example, a Dispatcher pipeline where the user wants to send out CC value 0 for the 1st note, 10 for the 2nd, 20 for the 3rd …120 for the 11th. Transform’s new capability does this in 2 pipes where before it took 11 very similar Transforms.
Similarly, see this old vs new image:
The old patch has 10 equally spaced notes being sent to 10 consecutive channels.
The same work can be now be done by
3 pipes...
- remap the note# → a note# that corresponds to the desired channel
- transform the note, preserving the note# but also setting the channel to it
- now remap the note# to the note# actually needed
Nothing wrong with the old version –indeed some may prefer it cos it’s easier to conceptualise– but the power’s there when you want it.
Thank you. This is theoretical to me.
Can you help me with a real world problem?
Problem: This patch ,upon pedal down of CC 69, will sustain any notes played on USB channel one, and, play any notes played on USB channel 2. Then all notes are off -on both channels upon pedal up. Perfect.
Why is it that if I change USB channel one at the end of the second pipeline to midi C, Midi C gets no note off upon pedal up?
Nothing else has been changed- only the destination of the initial sound. Is it because cc69 enters via usb? If so,
Solution sought:
how could I change the patch such that a note off message is received by Midi C and usb ch2 upon pedal up?
P4.CH1->2 c69…mhp (445 Bytes)
changed to
Midi C -sos- usb Ch 2.mhp (495 Bytes)
Thanks!!
Peter