Here’s my situation. I have a bunch of widgets on my global and normal racks that I want to control using a hardware controller.
But the controller has fewer encoders than I have widgets.
And I never need to control all the widgets.
So I thought what if I use several Rechannelizer plugins and switch between them depending on what I need to control.
But what I don’t understand is how do I get between the controller and the widget? And how do I make this communication bidirectional, given that widget settings only have one “Sync” button, one device to link to, and MIDI ins and outs are separate entities in GP?
I don’t know if this helps, but to the extent your widgets are in a local rackspace, you could just assign the widgets you actually use to the controller knobs.
So, I think this is only an issue in the Global Rackpspace. (Of course, I could be missing something here).
So, are you using more widgets than encoders if you only are talking about the Global Rackspace?
My local rackspaces are for guitar plugins, so they have like 5 common rackspace knobs, then there are 4 switchable amps each of which has up to 8 knobs and 2 switches, and each has it’s own EQ with 10 controls. Granted, not all of these need to be controlled from hardware, but in any case it doesn’t make sense to have 4 “Gain”, 4 “Bass”, 4 “Mid” etc. encoders dedicated to one rack.
Then there’s also a global rack where I have vocal plugins - gate, de-esser, compressor, FX.
It’s obviously not feasible to have a controller with these many knobs controlling each function. Only one guitar amp is active at any given moment, so I’d only need 8 encoders to control its parameters, 5 for common rackspace parameters etc.
I use Korg NanoKontrol. It has a fader, an encoder and three buttons for each channel.
One of the channels is assigned to Vox FX. The fader controls FX mix, the encoder controls compressor threshold. The buttons turn off gate, de-esser, but that’s not the best use really.
What I have in mind is to add the buttons to a radio group so that pressing them would alternate the fader action between gate threshold, delay mix and reverb mix, for example. That would require the fader to use different MIDI channels in each case.
@pianopaul that’s okay, I can use channel mapping in MIDI input blocks and switch presets maybe.
But the challenge for me is how do I even get between the widget and the controller? When I map a widget to a midi hardware controller, there are no inputs or any other type of routing involved, so there’s nowhere to put any channel remapping block.
You could experiment with adding a Local GP Port MIDI out block in your wiring view, connected after the rechannelizer. MIDI messages sent into the Local GP Port are then available system-wide in GP, so can be learned for a widget.
This unusual situation is where GP Script itself shines.
Don’t bother with other workarounds. Just use GP Script to respond to incoming CC messages on a constrained set of CC numbers (for efficiency) and then use flags to determine what widgets should respond
I think he is looking for a set of buttons that would effectively alter the incoming seen MIDI value of a single fader. For example, press mute fader sends CC1, press select fader sends CC2 press solo, fader sends CC3. Of course the fader would always actually send only one CC value but the script would need to remap it so that he could learn 3 different widget values from the same fader based on the button he pushes. I haven’t seen a GP script that does anything like that but I believe it may be able to be done in a gig script (but not a Rackspace script, song script or scriptlet. Is this something you have seen before?
No, what he is looking for is a way be able to use his small number of real encoders with a larger number of widgets.
What he suggested was an approach (rechannelizing) that he could use to accomplish this and I am proposing a different approach, i.e, use GP Script to respond to whatever messages his encoders are generating, then the MIDI callbacks could test a flag (controlled by another widget, say) to determine which widget should be controlled by a specific callback at a given time.
OK, or maybe he could use the same number of widgets but on callback have a given widget control a different plugin parameter. In that way he wouldn’t need more widgets but just be able to alter which parameters the existing widgets control. I’m not sure if that is possible with gpscript. Maybe MapWidgetToPlugin as part of the callback, then the CC controls the same widget but the plugin parameter it controls is different.
This sounds much like what I had been aiming to do with the external controller extensions I’ve done.
It’s conceptually simple, but can get a bit complex to program (at least for me). I started out very briefly doing it through gigscript but changed to the external API quickly.
Conceptually, my approach is:
identify what my physical controls are - e.g, a group of 8 buttons and 8 faders
create/organize my widgets in groups/banks that follow that organization
the widget are defined by gpscript names rather than being mapped to midi
the gpscript/extension intercepts the midi from the control surface and just has to decide which group/bank to connect that action to
This is similar in concept to having one group of those widgets on channel 1, another on channel 2, and so forth. In that scenario you’d have up to 16 “banks” available, and what you’d need to communicate to the script is how to “re-channelize” the incoming midi.
If managing it through code (gpscript or extension) then you don’t really need to use channels. Just use widget names that the script knows to look for. Using my 8 button, 8 fader example I could name widget something like:
vangrieg_b1_1, vangrieg_b2_1 etc. through vangrieg_b8_1
where the _1 at the end is sort of the equivalent of a channel number, but it represents a bank number.
so vangrieg_b1_2 would be first button in second bank, vangrieg_b1_3 would be third bank, etc.
Your script has to keep track of what bank your controller is currently supposed to control, so when you push the first button it would toggle the first button in the appropriate bank.
If you want the widgets to stay in sync with the controller then when you change banks you have to read the widget state for all the widgets in that bank, then tell the controller to move appropriately.
There are probably easier ways to go about it. Really depends on how complex you want to make it.
In practice, once you have that working it’s valuable to have some kind of visual feedback about what set of widgets your controller is mapped to at any given time. That can get tricky as you flip through rackspaces.
So here’s a basic concept (unsupported, just to suggest a direction)
In this example, I am sending values from CC number 93 via a slider on my keyboard.
Depending on which of the radio buttons is clicked, just one of the widgets will respond. Clicking a different radio button will cause the same slider to control a different widget
@dhj that script of yours seems to go in the direction that’s needed, thanks a ton!
One problem though is that the controller’s encoders don’t send absolute position values but rather repeats one CC value when going up, another one when going down, a third one for 0, and a fourth one for maximum.
So the widget knobs just jump from one position to another. When mapping a MIDI controller the usual way, I can select “Signed magnitude” instead of “Absolute”, so that works. Do you know how to recalculate the increment/decrement values into absolute position?
Also, do you have ideas how to implement feedback to the controller so that there’s visual feedback on the hardware?
