I’m working with a Korg nanoKontrol2. From scratch, in any rackspace I can add the input port for it ‘MIDI In (nanoKONTROL2 SLIDER/KNOB)’ and then see the slider movements etc. on a MIDI Monitor, route the data to wherever I want it to go, etc. All good, seemingly understood!
Now, if I make a slider widget in the Global Rackspace, like so:
I subsequently no longer see the movements of that slider in the original rackspace on the MIDI Monitor where I used to see them. It seems in some sense that adding that widget in the GRS supercedes or eliminates the data that was previously present directly via the ‘MIDI In (nanoKONTROL2 SLIDER/KNOB)’ .
Clearly there is a design aspect here that I need to understand, and I’m having a hard time coming up with the explanation via searches and docs.
So, if someone could either spell it out for me, or point me at exactly where to look to get clear on this, I would appreciate it. Thanks!
I can reproduce, but the more I think…
This could be desired behavior, it makes no sense to control Widgets in Local Rackspace and Global Rackspace with the same MIDI message.
A widget in a local rackspace mapped to a MIDI message will always take precedence over a widget in the global rackspace mapped to the same message. You’ll find that if you have two local rackspaces, one with the learned widget, the other without, the global widget will respond to the MIDI message when you’re in the rackspace that doesn’t have the widget.
To be clear, I’m only talking about one widget at this time, added to the GRS.
That widget seems to “eat” all the data from the assigned physical controller.
IOW, data that could formerly be seen and used in the original local rackspace is now absent.
I wouldn’t have necessarily thought that would happen, but obviously it does.
Offhand, my thoughts were: Do something with the data in the GRS that I always want done anywhere, while still being able to do something -more- with the data elsewhere when/if desird.
I opened you gig and can see that the widget in the global rackspace reacts on CC 23.
It is documented that MIDI messages assigned to a widget are not received anymore in other rackspaces.
That is documented
I don’t doubt it was intentional. I would like to understand the “wisdom” better, as on first impression the only effect is to shut down what I was aiming to do.
The default behavior is intended to prevent issues that have happened with other plugin hosts that break stuff.
Normally, in GP, one should use host automation to control plugin parameters rather than sending raw MIDI messages to the plugin. Sending MIDI messages directly is considered poor practice in the GP world and should only be used as a last resort. Hence by default, when you map a MIDI message to a widget, we block it from doing anything else.
