There are a few posts on how MuX could handle Program Change messages but I don't think this one has been floated.
I'd like to be able to use "Program Change" to affect routing dynamically. So a Program Change event processor module would affect which output subsequent event messages were despatched to. To keep things from exploding incomprehensibly, the module would have a single event input and sixteen outputs (like channel splitter). However, each output would be configurable to say what MSB, LSB and Program Change should be in effect to route events to that output (with a "default" option for everything not matched).
This way you could then have one "master MuX" which organised your workspace. You would wire up each "patch" inside a separate sub-MuX (putting it inside a sub-MuX is optional but might keep things tidier). A program change would send all subsequent messages to the selected patch (sub-MuX). This would allow flexible selection of set ups on the fly in a "natural" MIDI manner and also be fairly in keeping with the existing MuX architecture. The only thing is the new module would have a memory of the last MSB, LSB and PC events seen.
Of course, combining this with a MIDI Channel Splitter would be possible, as would combining multiple Program Change modules in a cascade formation (i.e. "default" leading to another Program Change module), to handle complex set ups with more than 16 destinations.
[FR] Another take on Program Change
-
- KVRAF
- Topic Starter
- 7137 posts since 8 Feb, 2003 from London, UK
-
- KVRian
- 852 posts since 3 Mar, 2009
Nice idea.
I was hoping that some (module/connection) On/Off switches could be automated, which would be equivalent to your suggestion. But Jo mentioned elsewhere that automated On/Off functionality is not going to happen for technical reasons.
Let's wait for Jo's comment
I was hoping that some (module/connection) On/Off switches could be automated, which would be equivalent to your suggestion. But Jo mentioned elsewhere that automated On/Off functionality is not going to happen for technical reasons.
Let's wait for Jo's comment
-
- KVRAF
- Topic Starter
- 7137 posts since 8 Feb, 2003 from London, UK
Some form of "memory" would also allow a lot of Continuous Controller based programming (i.e. route events down path 1 if last CC32 value was less than 64 else down path 2). Which would be nice. Any module with a memory would need a default state and some form of reset switch, too.
-
- KVRAF
- 12744 posts since 24 Jun, 2008 from Europe
Taken note of this FR. I've interpreted it as a FR for an audio/event/modulation signal dispatcher with 1 input and 16 (or N) outputs. Then a the second input is an event input and the events to that input can select the in->out map. How/which events are used can be further defined by editing the module. Eg via notes, program change, midi controller, ...
Sounds ok?
Note that all modules below the dispatcher, also the ones that are not currently active, will continue processing (and thus eating cpu), as they need to be stand by in real time.
Sounds ok?
Note that all modules below the dispatcher, also the ones that are not currently active, will continue processing (and thus eating cpu), as they need to be stand by in real time.
-
- KVRAF
- Topic Starter
- 7137 posts since 8 Feb, 2003 from London, UK
So to have "in stream" program change event messages control the unit, you'd wire event input to both the signal input and the control input. That makes sense - the two separate functions could well be coming from two different places. The map sounds ideal. I'd just suggest keeping the process flexible enough to allow multiple event messages (such as full MSB/LSB/PC sequences and maybe even Registered Parameter and Non-Registered Parameter Sys Ex sequences; I wouldn't suggest arbitrary event sequences but if you can get RPN/NRPN in it would be a great feature).
Yes - I would want the downstream to remain active as live switching is what this is envisaged for. I wouldn't want Kontakt suddenly thinking it should reload a drum kit.
(That's one problem I have with MuLab / Kontakt currently, compared with Reaper: stopping the audio engine to check what inputs I've got causes Kontakt to re-initialise, which takes a long time...)
Yes - I would want the downstream to remain active as live switching is what this is envisaged for. I wouldn't want Kontakt suddenly thinking it should reload a drum kit.
(That's one problem I have with MuLab / Kontakt currently, compared with Reaper: stopping the audio engine to check what inputs I've got causes Kontakt to re-initialise, which takes a long time...)
-
- KVRAF
- 12744 posts since 24 Jun, 2008 from Europe
To avoid misunderstandings: What do you mean with "the map"?pljones wrote:So to have "in stream" program change event messages control the unit, you'd wire event input to both the signal input and the control input. That makes sense - the two separate functions could well be coming from two different places. The map sounds ideal.
To be honnest i've not planned taking RPN/NRPN into account, sorry. I think it's too specific, and i must work on most requested things first. Of course i'll have to take note on/offs into account ie when switching an event dispatcher from out x to out y while a note is on on out x, i assume it should be automatically switched off. Agreed? Similar for sustain pedal messages, right?I'd just suggest keeping the process flexible enough to allow multiple event messages (such as full MSB/LSB/PC sequences and maybe even Registered Parameter and Non-Registered Parameter Sys Ex sequences; I wouldn't suggest arbitrary event sequences but if you can get RPN/NRPN in it would be a great feature).
I know why, the reason is on MuLab's side. This may be finetuned in a future release. Taken note.That's one problem I have with MuLab / Kontakt currently, compared with Reaper: stopping the audio engine to check what inputs I've got causes Kontakt to re-initialise, which takes a long time
-
- KVRAF
- Topic Starter
- 7137 posts since 8 Feb, 2003 from London, UK
What I was thinking overall would result in something like sixteen lines (that I called the map earlier - more a grid, really):
[ label ]|[ type ]|[ 1 to 3 values ]|[ output to activate ]
"type" would specify what the values meant (default, polyphonic aftertouch, MIDI note, NRPN, patch change, etc).
The values would then relate to the type. I think no more than three values are needed for any MIDI control (if you limit SysEx to RPN and NRPN). So for a patch change, you would have Program Change, Bank MSB and Bank LSB values. For types other than "default", each value would allow "any" plus 0 to 127 ("default" means "any").
*EDIT* you really want to be able to specify a bit more, to allow selection of ranges of events... "equal to", "not equal to", "< or =", "> or =" and "between"... although "between" could be emulated with two rows. You might get away with just "> or =" and build from that but you'd want to be able to "add row" to the map in that case.
A future enhancement could have a combobox made up from the label values, to display the currently activated output. This could then be usable to activate the output, also (optionally?) send the associated event sequence.
Finally, I envisage a "top to bottom, first match" approach to activating an output, allowing more specific settings to be entered along with more general ones that would otherwise overlap.
.
[ label ]|[ type ]|[ 1 to 3 values ]|[ output to activate ]
"type" would specify what the values meant (default, polyphonic aftertouch, MIDI note, NRPN, patch change, etc).
The values would then relate to the type. I think no more than three values are needed for any MIDI control (if you limit SysEx to RPN and NRPN). So for a patch change, you would have Program Change, Bank MSB and Bank LSB values. For types other than "default", each value would allow "any" plus 0 to 127 ("default" means "any").
*EDIT* you really want to be able to specify a bit more, to allow selection of ranges of events... "equal to", "not equal to", "< or =", "> or =" and "between"... although "between" could be emulated with two rows. You might get away with just "> or =" and build from that but you'd want to be able to "add row" to the map in that case.
A future enhancement could have a combobox made up from the label values, to display the currently activated output. This could then be usable to activate the output, also (optionally?) send the associated event sequence.
Finally, I envisage a "top to bottom, first match" approach to activating an output, allowing more specific settings to be entered along with more general ones that would otherwise overlap.
Personally, I would expect this not to be a problem - I tend to think quite strongly of events being discrete, though, so I'd be expecting the "strange" behaviour. However, for my use, I wouldn't be doing a patch change mid-note. And there are so many different potentially intended uses and meanings of control messages that trying to get it "right" by "holding back" the change in activated output might cause more confusion than it saves.mutools wrote:Of course i'll have to take note on/offs into account ie when switching an event dispatcher from out x to out y while a note is on on out x, i assume it should be automatically switched off. Agreed? Similar for sustain pedal messages, right?
Thanks! I've been thinking "must mention that" for months, of coursemutools wrote:I know why, the reason is on MuLab's side. This may be finetuned in a future release. Taken note.
.
