Best Practice for recurring Rackspaces and VST Mapping

General discussion about Gig Performer
1

Hi All, I have a synth VST (Diva) that I plan to use regularly for many different songs/rackspaces. I’d like to come up with a good widget mapping setup with my external controllers and then re-use that, avoiding have to map widgets each time I start to work on a new song.

Is the best practice to simply map it all out in a rackspace, save it, and use that as a template moving forward, or are there any tips and tricks I should be aware of to streamline this process?

Diva, being a rather involved VST, has parameters that could be mapped, that far extend beyond the dozen or so knobs on my external keyboard, any advise on getting hardware with pages of different knobs that could more comprehensively connect to more of the VSTs parameters? Even better, it would be great to have a repository of rackspaces for popular VSTs/hardware that are already made into templates.

Thanks!

Novation SL-MK3 Extension
2

In case it helps, I found this:

3

Thank you for this reference, very interesting.

Currently my main concern is actively editing using physically mapped VST Params. It would be fantastic to have a controller or two, cycle thru (maybe not all) but most of the important Params and not have to tweak patches with a mouse. Is anyone else exploring this?

I mostly tweak patches via mouse, and map Params to external controllers that are only needed in live performance. But using GP to actually edit patches of a vst would be really great. Wondering if anyone else does this.

Thanks

4

I have done that in the past. I haven’t done it in a couple years. No particular reason I stopped, other than I go through phases of spending a lot of time on “sound design” and then phases where I’m just not interested in detailed sound design because there are billions of presets available.

My solution for the “way more VST parameters than knobs on my controller” was to write a GigPerformer extension to allow “bank switching” of how the controller’s physical knobs/buttons/faders map to widgets.

Just to illustrate as simply as possible, let’s say I have a controller with 9 faders. If I want full control of a B3’s drawbars I need two separate banks of 9 faders (one for upper manual, one for lower). I’d set up a rackspace with two sets of nine faders and map those to the VST parameters. I refer to that as two banks of nine faders.

In the extension I put the logic that allows me to freely switch which of those two banks my controller is actively linked to.

Once that works well the next problem is being able to tell which bank of faders you’re actually currently connected to. I set my extensions up so that there is visual feedback on the GP screen and visual feedback on the controller (to the extent possible depending on the controller).

See Novation SL-MK3 Extension - GP Extensions for example, or MCU Protocol Control Extension - GP Extensions

As a practical matter, I choose my controllers based on how well they can accommodate this kind of thing, rather than trying to force an approach like this onto a controller that just isn’t very compatible with the idea.

For me the critical elements are that knobs must be “endless” and the controller must have at least some type of display. If I’m bank switching through 6 sets of knobs I’m never going to remember that LFO 2 shape is on bank 2 knob 5 for example. The SL-MK3 works well for this, as do many of the MCU-compatible controllers (I’d recommend the iCon P1-M).

If you really want to map out every significant parameter on the Diva you’d need somewhere around 10 knob banks (assuming a controller with 8 knobs per bank). That’s a lot to maneuver your way through, so I think good visual feedback on the controller is very important.

This can all be done through OSC as well, but I generally prefer physical controls to a touch screen.

1 Like
5

Thanks a bunch. I’m use the SL MK3 as well, and am aware of your extension. Researching this, I came across the Faderfox EC4, but before buying that I should probably try your extension, how many banks does it allow for?

6

As many as you have memory for.

It builds a list of as many as you want to create for every set of controls (knobs, faders, buttons, pads) and you can use the various up/down buttons to scroll through your groups.

1 Like
7

I’m planning out my Diva rackspace to be controlled by the MK3 extension. I’m thinking it will be one bank for the oscillator section, one bank for the filter section, one bank for the envelope section etc. as I plan, I’m wondering how careful I have to be from the jump vs how easily the extension will be to try out different things.

If I make bank 1 the filter section and bank 2 the oscillator section, then decide later to switch the oscillator section to from bank 1 to bank 2, what would a switch like that entail? Is it a whole lot of re-mapping, or relatively easy to switch things around?

I should probably just dive head first into the extension, but this will help me plan out my approach.

Thanks

8

You have to link all your widgets to the appropriate Diva parameters as you always do. That part will be the same whether you use the MK3 extension or not.

To tell the MK3 extension how to group them and sequence them if you’re switching through banks of knobs or faders you just have to change the GPScript names on the Advanced tab of the widgets.

You really need to read the manual a little before starting the widget naming process. The format is “sl_k_bankname_position”. It’ll become pretty obvious how that works when you read the manual or look at the example gigfile. The “bankname” part is how the extension knows which knob widgets (in this case) to group together. When you cycle through banks it cycles through in alphabetical order by that ‘bankname’.

You could choose meaningless banknames like A, B, C and that’s the order they’ll cycle in, but I don’t really like meaningless names. You could choose meaningful names like “filter” and “osc” and that would be great if they happen to be in alphabetical order. If not you could do something like “1-osc”, “2-filter”.

I’d definitely load up the example gigfile first and watch what’s going on as you page through things. You’ll probably have some “I like that” and some “I don’t like that” reactions. Replicate the things you like and don’t use the ones you don’t.

I’ll give you a time saving tip I don’t remember if I put in the documentation or not. When you start putting the names on the widgets like “sl_k_osc_0” and “sl_k_osc_1” you’re generally going to run the whole [0-7] sequence. If you name the first one “sl_k_osc” (and intentionally leave off the _0) you can copy and paste that name into the next 7 widgets and it will automatically name them _1 through _7. You then go back and rename your first one to add the _0. GP does this because if you try to create two widgets with the same name it will append “_1” to the duplicate, then “_2” to the next duplicate and so on.

That trick not only saves time when naming widgets the first time, but if you need to re-label a whole bank because you want to change the sequence you page through them in, it’s pretty quick to just rename the first one as I describe above, then copy and paste that into the next 7.

2 Likes