The ability to send MIDI data directly from an instrument track would be intensely helpful for when MIDI data needs to be monitored from and/or needs to control an external source.
My current workaround is to build a MIDI track and route that to an instrument track while also sending MIDI CC data from the MIDI track. I can send the MIDI data from the MIDI track to an external source and have it match the automation data for the instrument track. While this allows me to route and use that data, it is painful to have to build two tracks to properly control and monitor what should only require one track.
Use case example: Sending MIDI data to an external physical controller like a motorized fader bank or to a software virtual controller like Lemur so that those controls reflect whatās actually happening with parameters in a trackās VST software. As I said, this can be accomplished by building a MIDI track that sends to an instrument track, but this results in a cumbersome setup and visual clutter.
I own, use, and love SD3, but the mentioned feature only helps for that application and doesnāt represent a solution to the posted problem. SD3 is designed to work smoothly with external digital kits and, by default, really needs to be able to send back to those kits for full integration with those types of setups. Itās fantastic that it does that internally and kudos to Toontrack for implementing that feature; although their standalone product would have far less adoption without it.
What I, and I suspect others, would like is to be able to control and view the control changes of additional parameters within any VST, both during recording and after a part has been recorded, using an external controller that takes cues and feedback from the recorded data WITHOUT having to add an additional MIDI track and build a send/return just for that data. Physical, external interfaces that need to respond in real-time to automation data just arenāt as useful if they canāt mirror that data.
Iāve been through a long line of DAWs in my time. The most recent was Reaper. While that DAW has definite issues with its implementation of MIDI (my most recent experience was with Reaper 5) its method of sending and receiving MIDI for individual tracks showed me a better world that will most likely be realized in Cubase. Iām just longing for the day when I donāt have to set up a separate track just to record and externally view additional MIDI data into what is already essentially a MIDI track in the form of an āinstrumentā track in a DAW that I want to use as exclusively as possible.
A step further, Iād love to see audio tracks in Cubase be able to directly accept and edit MIDI data in time with audio data WITHOUT having a second MIDI data track, but Iāll wait until the first bridge is crossed. An example of where this would be useful - Using an external controller to make real-time changes to a guitar VST strapped across an audio input. Yes, I can do this with the current workaround at the top of the thread, but it also means that 1/3 to 1/2 of the tracks in my mixes are just MIDI send/receive busses to control external automation. It feels like an unnecessary slowdown to the process.
EDIT: This post is for the use case of sending midi data entered in Cubase to two or more destinations. - For the use case of having the VSTi send midi data to external controllers, see the post by @skijumptoes immediately below this one.
In the meantime, you could just add instruments in the VSTi Rack (rather than as ātracksā) while ensuring that your Preferences > VST > VST-plug-ins are set properly:
You can do that via the generic remote editor, of course. If you map an external control to a plugin and set the control to receive and transmit - moving that parameter onscreen will move it on your controller (providing it offers feedback).
Same applies to quick controls if theyāre setup to transmit too.
What i donāt get is if you had MIDI out from an instrument to a controller in the method youāre suggesting, what would happen if you had multiple instances of the same plugin and they were subject to automation changes - Conflicting MIDI CC data would be sent out to the controller wouldnāt it?
I appreciate you posting. Iām not sure if I was completely clear in my initial post.
You are absolutely correct in that you can use the generic remote feature to send data from an external device into a VST (without an additional MIDI track). You are also correct in that you can use the generic remote feature to receive data into an external device, but to do so from within a VST track requires the use of a second MIDI channel to act as the send. You currently cannot set up a VST based track (instrument track) to send MIDI data to an external source without using a second MIDI track to facilitate the sending of that data. Thatās what I would like to see addressed in future editions of Cubase.
Multiple instances of the same plugin, or any VST for that matter, donāt pose a problem in terms of conflicting MIDI data of any kind, be it note, patch, or CC data. You can either separate things by channel, or if youāre less OCD inclined you can have your external controller only focus on the selected track(s) that contain your VSTs. In my case, at least, itās rare to focus on making changes to more than one or two VSTs at a single time when working on any given project. For me that works out because I generally will have a different load-out on the external device for any given track in a project. Those load-outs can be set to autoload when you select a track and refresh the external hardware.
Thank you so much for the reply. This is AAAAALMOST what I need. Iāve tested it and verified that it works within a SINGLE VST in a rack module. I can use this method to build and control AND MONITOR on an external device when using a rack module, provided the VST has decent MIDI programming capability. There are a few caveats to this that donāt make it a complete solution for me, but it does get a huge step closer to what Iām looking for. One of the biggest caveats is that getting quick controls assigned and running reliably can definitely be a little iffy when trying to run additional effects inline with the VST rack. A lot of internal remote editing work within Cubase would possibly help, but I prefer to keep my control sets loaded externally to Lemur and have them load as I switch track focus. I suspect trying to do this in Cubase would be very painful since I would need different functionality with every VST.
That said, Iām looking at this as a huge win. Using the method you described, I can now run a MIDI device, such as a keyboard, assign external faders, X/Y pads, etc. using Lemur on a second device, have all of the input properly received, and have those automation changes sent in real time to the Lemur controller so I can view the automation immediately without having to make any repatches; all while only having one visual track.
Having MIDI sends as well as receives on āInstrument Tracksā would still be a much easier way of working in the long term, but this gets me closer to performance based recording rather than programming style recording for VSTs.
I suspect this method will also work well with external motorized fader banks, devices that use infinite rotary encoders, etc.
That would map to the cutoff parameter on retrologue, for example. And if the generic editor is set to transmit as well as receive, it will output the changes to that parameter back to your external device.
Sadly i havenāt got a controller by me to confirm 100%, but iāve been using this with my controllers for a long while to even doubt if it works. When you change tracks you can see the controllers update if you use the āselectedā mapping options too.
But maybe this isnāt precisely what youāre wanting? But it sure fits the initial quote that i replied to.
