Method 1a (Simplest):
Use the Global or Local Project/Track Transformer. It might be enough to echo off a second CC. This would work if you simply need duplicate CCs spawned from a single fader/pot to run multiple Quick Controls, or Controls in a single instrument/MIDI track. If you can get it done with 4 sets of logic in a single Transformer, you’re all set.
I.E. Clone a copy of CC67 as in comes in from a fader and send it as CC68.
Method 1b (OK for simpler things, that require ‘more’ MIDI transformers running in a ‘series’):
Sometimes you need to process the MIDI more than once…through a series of transformers each running different filters. MIDI tracks allow you to use more of them, in combination with the main Track Transformer.
Install a Virtual MIDI port if you don’t already have one. Route your controller through a MIDI Track with channel set ANY, and output to your Virtual Port. Arm the track (for Monitoring, or even recording if you’d like to record here as well). Routing it through this MIDI track first allows you to use MIDI Transformer inserts to spawn off new CCs, manipulate them in real time, and more.
I.E. The main Track transformer might simply filter out all Note On/Off events. As a MIDI Insert…you might then have a transformer that listens for CC66. If it gets it, it might then filter out CC66, and instead send ‘both’ CC67 AND CC68 events with the same values.
A second transfromer insert running in series might then MIRROR CC68 (reverse the fader). Now you have an X/Y crossfade kind of thing going on.
A fourth transformer might then compress/scale CC67 so it’s lowest value possible is 64, highest 128.
From there, learn those controls in the respective plugins directly. Hence, moving one fader on your MIDI controller could end up actually sending CC67 AND CC68 (with CC68 inverted, and CC67 compressed into a ‘top half’ control) to all instruments listening to your virtual port.
Set the MIDI input of your other tracks that you need the extra data for to use your virtual port.
Method 2 (Best for controlling darn near anything in the DAW at any time):
If you have Cubase Pro, you could do it with a Generic Remote. You’ll need to ‘stack maps’. By this, I mean, have more than one active at the same time, and listening to the MIDI port of your controller.
Example:
Create a generic remote. Make sure any instruments/plugins you wish to control are loaded and active. Set the remote map’s MIDI input to your MIDI controller. Learn a control, and assign it to pretty much any registered VST parameter in the DAW there. Actually, you can control almost anything in Cubase from here (including launching macros, running logical editors, etc.)!
If you install some virtual ports, you can get really creative, and direct MIDI tracks to these maps and automate a lot of things in Cubase that don’t have native automation track types (such as stopping the transport, moving the cursor around, toggling monitor on/off for various tracks, and more).
Personally I like to do it like this:
My MIDI Controller > Cubase MIDI Track > Virtual Port > Generic Remote Map.
Why route it through a MIDI track like this first? It makes it possible to record/edit every move I make with my controller on an easy to edit/process track. I can also use the real time Cubase MIDI insert effects (Local/Global/Transformers, LFO generator, etc).
I can draw stuff in directly using one of the MIDI editors. I can use the MIDI Logic Editor to do quick batch edits to this stuff! For what it’s worth, while the VST lanes have higher resolution in theory, the editing features for them are quite bare. Not so for a MIDI track! Since the INPUT came from MIDI anyway, why not take advantage of these outstanding MIDI editors? Also, it’s nice to be able to keep several different versions of these ‘automation tracks’ at hand, take advantage of stuff like ‘cycle recording’, and of course…Retrospective MIDI Recovery!
I can have as many of these remote control tracks as I like! I can route to different arrays of virtual ports and generic maps at will…just choose the one(s) I want by arming/disarming them (one click, or I can even remote control arming/disarming the one(s) I want active).
Later, before I archive the project, I’ll want to hard code my best takes into the VST lanes directly so the project plays back even if no generic remotes are set up (just activate the desired VST lanes for ‘write’, hit play on the DAW transport, go have a coffee). I can hard record/write the stuff to actual VST lanes if I like then mute or ditch the MIDI version (or…if I like…not even record in the MIDI track, just arm it with ‘monitor’ and set the respective VST lane(s) to ‘write’ their movements directly).
To get one control doing multiple things in the DAW: Repeat the process, as in make a completely new Generic Remote map. Set its MIDI Input to your same controller source again. Learn (or type in) the control again, but this time assign it to the secondary VST parameter.
If you want a single control to drive 8 different parameters in one go, then use 8 maps. Etc…
The reason you need to use multiple maps? If you assign the same control in the same map more than one time then only the first one in the list gets triggered. By stacking multiple maps in such cases, that one CC can do more than one thing at a time.
If you want stuff like X/Y crossfades…or to scale one parameter independent of others…it’s easy as pie if you route things through a MIDI track first. I.E. Use a serial pair of insert logical editors to spawn a new CC and mirror the second.
Stuff to know:
Cubase Pro, up through version 12 still supports (Legacy) Generic Remotes. There are disclaimers in Cubase Pro 12 stating that these Generic Remote maps will be depreciated at some point in the future.
Also understand that using the Generic Remote system sets up static links. They do NOT save with a project, but rather, become part of your DAW settings. Some things you link might be based on track and slot order, so changing the order of tracks in your project means you might need to make adjustments in your Generic Remote Map respectively. In the case of controlling VST Parameters in plugins, it generally goes by 1> Name/ID of Plugin. 2> Instance order if more than one instance of the plugin is running, in order that they were added to the project (take advantage of project templates if you work out a nice work-flow that’ll get reused often) 3> Parameter Name/ID. The good news is that it’s pretty easy to pop that map open and make changes to your remote map on the fly as you need them.
After you build a generic remote, it’s a good idea to export a copy of it right away (sometimes they don’t work quite right until you’ve exported a copy) and store it with your project. Make notes and store them in your project folder too! Remember, generic maps do NOT save with your project. They are independent DAW settings.
If you use my method of routing things through tracks first and storing such automation on MIDI tracks…it’s a good idea at some point before putting the project away to record it all in the actual VST automation lanes, then mute/disable the MIDI version. Why? That way if you revisit the project 3 years down the road in a DAW that doesn’t have all your remote maps and stuff set-up and working, it’ll still play as intended!
Cubase 12 has a new system for dealing with controllers. You could do something similar with these as described above using the old Generic Remote maps. At this time, I personally don’t know how comprehensive the newer MIDI remote features are in terms of establishing links to registered VST parameters to build the scripts, but it should be possible (I just haven’t tried it yet). Same concept as the Legacy Remote system. Stack remotes (might need to edit the scripts directly to get more than one of them active and listening to the same MIDI input at the same time. Might need some virtual ports, etc.)