Multiple Program Change Transmissions

I was sitting here tonight trying to make sense of how to map CC to Bank->Program Change, I’m not entirely sure yet here, but I found another little problem while working on this.

I am a live keyboard player, old-school with master keyboards, keyboard synths, synth modules and external effect units, and I would like to setup a bunch of performance pipelines that responds to either one single program change, or to a control change, per pipeline.

Each performance pipeline would then need to send bank change and program change, to one to many midi outs, on one to many midi channels, depending on the performance pipeline.

How do I do this the smartest way here?

I can’t seem to find a bank and program change module, or am I missing something here?

Ideally I’d just setup a module that responds to incoming and activates the actual process with say a given CC or a program change, and then depending on the incoming value, triggers another module, or multiple instances of it, sending out the actual bank and program change messages to the different ports and midi channels.

Any ideas?

Hey JFN,

I’m not 100% sure I understand your setup/aims here but here are my thoughts on how to achieve what I think you’re trying to do:

  1. Basically you’re trying to achieve some sort of conditional routing - like an “if” statement in a programming language - inside the MIDIHub based on varying program change input values, right?

  2. If so, the newest Editor update (released two days ago) allows you to use the Transform module in conjunction with the incoming data bytes. Therefore, you have access to the one data byte passed along by a PC message (the new program number) and can pass this forward to some other things. For example…

  3. From MIDI A => Transform. Now you can change your PC message into something that MIDIHub can more easily remap, like a CC value, but pass on the data byte from the PC message to your new value. Now what you have is a CC message (for example) whose value is based on the incoming PC message value, and can now be dealt with accordingly. Send this now to => To Virtual A.

  4. Now you can use multiple instances of the “From Virtual A” to deal with this message. Follow each => with a CC Range filter, which can choose whether or not to ultimately pass on the data to either another Virtual Output (for further processing), or just through a Transform pipe back into PC data (with a new value for your next device) to your final hardware output. For example, you could have 5 instances of “From Virtual A” each set to only pass on one particular value for CC data, all of which then get transformed into some new PC message, and sent to hardware MIDI output A. Now whatever synth is connected to this particular output should respond (or not respond) accordingly.

  5. That’s obviously a simple example regarding just 1 synth. To work with multiple synths (and multiple processing logic) I would conceptualise each one as having its own Virtual chain/letter. So, for example, a Prophet on Virtual A and a DX7 on Virtual B. Once the initial PC => CC (or something else) conversion is complete, you can route it to Virtual A then have another pipe passing this information straight to Virtual B for whatever processing needs to be done prior to passing it onto the DX7. This will then operate independently of your Prophet processing. They can be passed onto separate hardware outs if that’s how you set things up, or you can use some additional Virtual processing/routing to selectively ignore/discard certain channels or types of info.

As I say, I’m not sure I’ve fully grasped your aim and I only got my MIDIHub a few days ago so I could be getting confused myself…but as far as I understand it, these steps are at least one way to achieve some form of conditional routing. The immediate problem I could see is that this solution is extremely inefficient, and I’m not sure of/haven’t tested the MIDIHub’s limits as far as the number of pipelines you can have and how quickly things can be processed.

2 Likes

Just had a look at the example “ProgramChange to Multiple Ordered Events” included in the most recent Editor update, I think this could also be a good starting point for you to explore…

1 Like

Hi, thanks for your suggestion.

What I would like to do, is to trigger a preprogrammed series of bank & program changes, based on something I send to the midihub, a program change, a CC, etc. And with this, be able to setup a number of pipelines, one for each “performance”, to setup all my machines automatically for each song/scene etc.

I have investigated the transformation, and yeah, I am sure I could hack something, I just need to find out how I can do with the bank messages preceding the actual program change message.

Ideally a “bank/program change” object would’ve been great, with a list of all midi channels, and then a field for “bank” and “program” for each channel, or something in that direction, with a “trigger” (map) to fire it off.

Aha, OK, I think I understand a bit more now.

I’m not sure I have the solution for you unfortunately!

But I wonder, if the message is coming through as some CC values for Bank Change then a value for PC, could you use the Filter on two separate instances of (for example), hardware input A? One to only allow PC data, one to only allow CC data. Then process and pass them on accordingly?

You could then combine them using Virtual Outputs and send them on, or even time the messages appropriately using a method like in the “Multiple Ordered Events” example above to send CC(Bank Change) first then PC.

I think you’re right in that whatever you come up with will be a bit of a workaround, maybe post in the “Feature Request” section asking about plans for Bank Change data, as I’ve found the project to be very responsive so far! Good luck.

1 Like

Yes, in theory there’s probably some ways around it, but it will become messy when there’s a bunch of changes to do, with both bank and pc, and the transformations etc. to all of the destinations…

hehe!

You may use Transform pipes to produce both the bank select (which is just CC #0 (coarse value) and CC #32 (fine value), as I understand most synths don’t have >128 banks, so CC #0 only is used), and a program change value.

The ordering is controlled using the ‘mode’ argument, whether the transformed message is actually replaced, or a new message is prepended or appended to the data stream.

Could you give us some concrete example of what you want this to do, in terms of an input event, and the expected outputs?

2 Likes

Thanks!

I will have a look next time I have a moment to sit down with it, and get back to you.

Cheers!

1 Like

Hi, I try to operate with mine but not sur of your explanation. I don’t find how to send a custom PC#, with the “Transform Pipe” we can transform a PC# into a PC# but impossible to choose wich PC#… I should miss something.
My final goal is to use a TC Electronic G-System with multiple devices and this product can only send a custom MIDI PC# map and associating MSB.
Finally I’d like to send a PC# from the G System to the midihub and change it so I could send 4 different PC# on 4 differents MIDI channels. It seems more harder than I thought :frowning:

You can use the rear button, long press.
The following example sends
: on MIDI Channel 1 - Program change 6 AND Bank 2 (CC0 value1)

got to Preferences (screen below)

edit: Notice where to Send out this Custom MIDI message;-)

The Transform pipe can be used for sending preconfigured program change messages - make sure to use >= 1.11.3 editor version, and pick ‘Arg1’ in the Data Source 1, and enter the program number into the Arg1 property.

Let us know the input and the desired outputs, and we’ll help you come up with the preset for it. :slight_smile:

Thank you for that tip, but I need to have a complete MIDI Map so I can have a new preset for each preset of the G System. This tip is very limited for that.

All good @FrogT, sometimes it’s hard with few words to know the use case someone is idealizing; and I “over-cooked” the solution this time…

Okay I just updated the editor and the firmware to see the new transform Pipe, but I think I don’t use it as I should…
Here’s my configuration on my transform pipe.

  • First I take my signal in the MIDI A port
  • Then this screen capture

  • Then go to the MIDI port D where my Nemesis Delay is plugged.
    Then I realise that it take whatever MIDI PC# and apply the new one but it’s not a MIDI map. I need an output Midi Channel router, but don’t find it, do I miss it??

Yes, thanks for your help anyway!

I just need the same control as with my OneCOntrol CrocEye, when mapping a MIDI message to the input of my MidiHub, I want to transform it in what I need.
For exemple :
For the preset 00-1 of my G System, there is a MIDI PC# sent on channel 1.
I want it to become a PC#00, CC#00 on the MIDI Channel 3
Then for the preset 00-2 of my G system, I want a PC#10, CC#107 value 40 on the MIDI channel 1

Am I clear? Thanks for the help you could give me.

EDIT : I don’t really need to send on different MIDI channels by the way, because I can use the 4 outputs, each one for one device to control. But I need to change my input message to transform it so I can control one or 4 or no device on my ouputs… I still look for my good configuration :roll_eyes:

EDIT 2 (because I’m new and can’t reply for the time)
Yes that’s a solution, but my MIDI message is not the one I need, It’s like the G-system always send his own map and we can’t go through.

Just use CH Remap no? (remap ch1 to ch3)

So, I think I don’t understand the G-system MIDI output. I Tried to see the MIDI activity with Pocket MIDI and MIDIox, but nothing happen. I see the led of the midihub blinking when I change preset on my G System (with MIDI parameter on “On”, or “OnMap”) but can’t see nothing on the MIDI monitors… I think I’m a newbie with this protocole sometimes :sweat_smile:

Did you send the MIDI activity to one of the USB outputs?

Sure! I did it, so I’m frustrated for now