General philosophy of creating plugin controllers

Having gotten somewhat frustrated with trying to create presets that control every aspect of a software plugin, I am shifting my focus to create a more “universal” E1 preset with just the basics- filter, amps, envelopes, LFO’s, etc. so that it will all fit on one page. Since I have my E1 right next to my MacBook Pro, I figure I can go quickly back and forth between quick access on the E1, and adjusting more esoteric parameters on the Mac. Also, some plugins can be ridiculously complicated (Zebra2). I downloaded a list of the CC assignments of the Novation Peak, which seems to be fairly typical.

Now if I had a hardware synth, I would definitely want to control every available parameter. One of my goals was to set up a controller preset for the Waldorf Microwave 1, but then they went and released the M last fall and made that plan superfluous… :grin:

Interesting thought. So I guess a kind of meta-preset would be desirable, one that has more or less the same layout for every VST, but yet is combined in one preset, so enrichments can be made available to all of them by programming only once?
Actually that is doable with the current lua, and this preset could work bidirectionally as well, but in my current thinking I’m doubtful patch parsing would ever work. This being said, patch parsing is probably not the issue for vst’s anyway, so I’ll assume you won’t need it.

I’ll also assume all the vst’s have different names , values ranges and cc assignments for each of their functions.

Here are the steps to do in my opinion:

  • design the generic preset but all controllers are to be virtual in nature
  • create a giant array where for each of the vst-controller combinations you may define name, color, hiding, min and max display values, type (cc , nrpn, rpn), cc number
  • have a selection list where you choose the vst model to control, this list should then define the index with which to search in the giant array. In other words one preset could control dozens of vst’s
  • create one single function called by all controllers, that will construct the appropriate midi message(s) based on the attributes found in the giant array.

In other words the preset would not be making much use of standard cc / rpn functionality, we’ll have to reconstruct those, but that is not difficult.

The main effort wil be in creating this giant array. It would be a lot of knowledge going in there, and we should do it in such a way the work is useful for anyone, even if the only have one or two of the vst’s.

There are also possibilities to sync the E1 to incoming cc messages but this may be a bit too much for a first reaction :nerd_face:

As above, vsts these days have a ton of parameters, so I’d never try to map them all manually.

Also it’s not just the preset generation , unless you use automation you also have to assign a ton of cc… and that means potentially midi learning every param in your daw.
Really unless you use the vst everyday it’s sounds like too much effort.

I think the better solution is a programmatic one
Basically take the same approach as push2
You wrute control scripts for your daw, that interrogate the plugin via automation… and then dynamically create that in the e1
But that’s quite a lot of work, and is also dependent on the daw.

there’s another approach which I’ve done in the past which is host vsts within a wrapper vst … that is more daw independent but has a few limitations.

Another simple / halfway house. approach would be to write a vst host,
That simple interrogates the vst, and the produces an e1 preset file , with cc mapping.
Then you could load that up to move things around , and then midi learn to params in your daw.


But for now , I went entirely the other/simpler way.
I think of the E1 as a performance interface , so presets are created just for what I’m using , where I need.
So I’ll combine things like level controls all on one page, even though they are for different hardware and software synths ,

Well, as it happens I ran out of memory with my Korg 03R/W preset (while adding additional data in the arrays) this morning, using the same principles as I’ve outlined here.

So as long as I haven’t found a decent way to optimise memory, I believe my suggestion wouldn’t work once there would be a bulk of VST’s in the array.

So, I am just a simple musician/MIDIdiot, I can assign CCs but all this talk about programming, LUA, etc. is way over my head. My plan is to create a one page preset, probably only 20 or so parameters plus 4-8 “wildcard” controllers for special functions (A-H). This should be easy enough to assign manually to each VST, and make the control interface consistent. If there is some way to have the VST settings sent to the E1, that would be great but I am utterly clueless in this regard.

The Waldorf M is an absolutely amazing synth, btw. Pretty much perfectly recreates the Microwave 1, with a knobby interface, filters that more closely resemble the PPG, and added functionality of the MW XT. Vlad is in the process of finalizing interface updates, and I can see using the E1 for CC control of the additional parameters.

Keen on seeing the result of the preset, i can help testing then :slight_smile:

Well so far, I am implementing 14-bit messages incorrectly; specifically for filter cutoff. I will attempt to figure it out first. “MIDIdiot” It may also be that I have to set up CC control in the VST to accept 14-bit messages.

Also it would be great if there were a quick “double tap” to open the expanded graphical interface for the envelopes, as opposed to two longer, more distinct taps. Either that or some kind of more always available 4-space graphical interface. The only other option currently is four separate sliders.

Have a look at my presets then , for instance the one for the Matrix 1000. You’ll see that for common ADSR’s I repeat the same EG four times , but every time with another parameter presented as the main one. Easy to do. And it will give you what you look for

1 Like

One approach I’ve been taking for hardware synths is that yes, for some gear (and for learning purposes), I’ll implement controls for every parameter (Alesis Ion, tc 2290 - eventually).

Others though, I am trying to find either parameters that are buried deep in menus that I use a lot or parameters that are easier to see the values on the E1 (example is the Mod Matrix for the microWave XT).

The final approach is for parameters that I want to control in real time and can record the MIDI CC/NRPN data while doing so (current example is the sample start/end and loop start parameters for the Isla S2400. Also because I can add logic to prevent the start/end points from being the same which cuts off the sample).

The point being - thumbing through lots of pages on the E1 is not much better/different than thumbing through a lot of pages on the target hardware. You can apply a similar approach to the VSTs. Pick the params you tweak the most, put them on 1 or 2 E1 pages and move on.

What daw are you using?
I’ve developed a Java -extension for bitwig that maps vst parameters to the e1.
It’s not really done but more or less in an alpha state.
I’ve made a system where you make a text file with parameter numbers and vst names so you can make your own mapping that will show up automatically.
But if course, only bitwig…
But if anyone’s interested I can put together a version that people can try out.

Ah yes, I see! Much better than just the four separate sliders. Also, I figured out what I was doing wrong with 14-bit CC control, it should have been set for “LSB First” and now it works, at least in DIVA.

Anyway, I have published a preliminary version that should be otherwise workable. I may refine it or add a couple more parameters, but will still keep it relatively simple and straightforward.