Hi all - my first post so go easy! I’m right at the start of a GP trial having being working with MainStage for some time, and would like to know if GP has a way to map physical controls/incoming MIDI CC’s to parameters in plugins that the devs of that plugin haven’t bothered to make addressable? Example - Eventide Blackhole - plugin patches/presets and the buttons that allow you to step through the presets aren’t MIDI assignable (although many of the variable controls are) - is there a way to use GP to link a physical MIDI controller and somehow address these buttons or patches? Maybe GP could recognise the GUI element somehow?
If it’s not midi assignable, unfortunately there isn’t really a way of doing it as GP doesn’t even know that parameter exists.
For your specific example, however, GP has it’s own preset management system - which is very good - for each plugin and it would be possible to use some very basic GP script to be able to control the selection of presets by MIDI.
The use of preset selection generally isn’t advised vs the use of rackspace variations and widgets though - going the variation route will give a much more stable experience when performing.
And welcome to the community! (should have put that first…)
1 Like
Perhaps there is a way to do so using Bome MIDI Translator Pro (MIDI Translator Pro – Bome Software) which has a built in mouse emulation. But, as I don’t know exactly how it works, I cannot tell you for sure. Perhaps you could just try the demo version? If @SteveC-Bome is around, perhaps he could tell us more.
Thanks for the replies - the combination of preset management system/GP script sounds promising - gives me a target to explore during the trial period! Any pointers to further info (like tutorials that might help) would be great but assuming that a bit of googling will lead me there 
Bome also a potential option but as I don’t own it the first suggestion sounds more cost effective of course 
Examples (LoadGPPreset):
1 Like
First of all, you shouldn’t be trying to control plugins directly via MIDI and instead you should be using host automation parameters (map a widget to the desired parameter)
That said, if the plugin doesn’t support host automation for the parameter you need, then you should reach out to the developer and ask them to fix it.
In the meantime, as others have commented, you can use GP’s preset management.
1 Like
If the GUI elements are windows objects (Windows Only), Bome MIDI Translator can map MIDI messages to keystroke, and mouse click event objects. If the element is not an object or it is on Mac, then you can still send events to the currently focused application. Keystrokes are usually easier as you don’t need the exact location of the GUI element. Otherwise for mouse clicks you need to have known location (that does not move) and you can send a mouse click on the GUI element.
Here are a few tutorials that might be helpful:
Use a MIDI Controller as a Mouse
Controlling a Mouse Wheel with a MIDI Encoder
If you have any questions with any of these tutorials, feel free to reach out to us on the Bome Forum.
There are links to the Bome Project Files for each of the tutorials in the YouTube Comment. You can try them out for with the free evaluation copy of Bome MIDI Translator Pro.
Steve Caldwell
Bome Customer Care
1 Like
As @dhj said, it is better to set the parameters within a variation and then use different parameters in each variation to define switch presets. Then by simply switching variations you will be covered and not need to do MIDI to mouse actions.
In looking further, Eventide Blackhole will not handle injected events and with my testing, I could certainly click on the left and right arrows using my MIDI buttons and Bome to mouse clicks, but the plugin would need to be in the same place on the screen every time so it would not be as reliable.
You could still use Blackhole preset. Just select a different preset within each variation and when you select that variation in Gig Performer, the Blackhole preset would also be selected.
SteveC
1 Like
This is absolutely correct with the minor caveat/clarification that the parameters would all need to be mapped to widgets for this to work - however that is still the best way of changing presets so would agree this is probably the best approach for the OP.
Hey thanks everyone - much appreciated. The variations route seems the most straightforward approach. Shame it requires 12 continuous control widgets and a switch widget to ensure all parameters change as per the preset but I guess that’s the price of using an underdeveloped plugin 
I’ll ask my follow up question about grouping widgets into a single object in a separate thread…
At least you can do that!
2 Likes
yes of course - sorry about my ‘glass half empty’ comment!
In isolation this is similar to MainStage, but the option for variations is neat and avoids having multiple instances of the same plugin (at least that’s what I think is happening…)
1 Like
So I’m returning to this thread as I have a further challenge/question:
I’m a guitarist looking to create a virtual pedalboard, so if I was to set up a Rackspace with multiple plugins, and a set of widgets mapped to the controls of each plugin (so a set of widgets per plugin to represent say virtual foot pedals), and each plugin has the problem of non-MIDI addressable presets, presumably there is no easy way of addressing all the presets of one plugin in one go, leaving those of another unaltered, then address all the presets of the second plugin in one go, leaving the first unaltered and so on?
I think with variations all parameters of all plugins would update to the value saved in the variation so this would affect those mapped to the 2nd plugin while only wanting to affect those mapped to the first and vice versa.
I could probably achieve what I am after with multiple MIDI messages from a controller (each one mapped to each parameter of the plugin) but that is v cumbersome!
With plugins whose presets can be chosen by incoming MIDI message there is no issue of course, as a single message will update all parameters relating to that plugin.
Any ideas?
Why not use different rackspaces?
1 Like
I’m not sure what issue you see here? If you don’t change a widget in a specific variation, then its value won’t change. This means that some of your variations can only alter parameters for one plugin, if that’s what you want.
As @pianopaul indicated, using separate rackspaces solves the problem for plugins that don’t expose their parameters, or where you don’t want to set up widgets/variations.
It’s good question - but what I am hoping to achieve is the equivalent of a guitarist’s pedalboard, with all effects (Plugins) available simultaneously rather than one at a time. So switching on effect 1, choose preset 3, switch on effect 2, choose preset 2 and so on. Hope that makes sense
I am wondering if the option to use GP’s preset management might be a way forward? If so - a pointer at some beginner resources on using this would be great as I’m struggling to find anything in the manual/Google about it (obvs using the wrong search terms).
In the traditional sense, a pedalboard is just switching individual effects on and off. You can do that easily by adding a button widget to each plugin’s bypass parameter. You can then either:
- Midi learn each widget to a button on your foot controller, and turn them on/off individually, like a traditional pedalboard
- Use variations to turn multiple effects on/off in one go, more like the pedal switchers.
If you need more extreme changes, you can then:
- Use multiple versions of the same plugin, and using variations to bypass/activate them as required.
- Use separate rackspaces.
Both of the above can allow you to have seamless switching and e.g. have reverb/delay tails continue.
Using presets on the other hand may not be seamless.
1 Like
There were some links in the first few posts about using scripting to switch presets
Here’s another useful post:
Excellent - thanks for the reminder - I’ll take a look