The problem is the following : using two MIDI tracks (named EX_ch1 and EX_ch2), both routed to EMulator X (multitimbral sampler), respectively on channel 1 and 2, I wanted to check the channel of outcoming MIDI messages sent by the second one. So, I created an additional MIDI track (named EX_Rec2) to receive and record them, expecting to be able to route directly the output of Ex_ch2 to the input of Ex_Rec2.
It isn’t the case : to do so, I also had to use a virtual MIDI port (LoopBe1), as apparently, the output routing options of a MIDI track include MIDI ports available, as well as instruments already loaded (either in the rack or in an instrument track), but NOT others MIDI tracks already present in the project.
So, my question : is it mandatory to use a virtual MIDI port to record the outcoming messages of a MIDI track or is there a more or less hidden routing option that could avoid doing so ?
In cubase there is no option to route a midi track to another midi track.
BTW I dont see a reason why it woul be needed - what is your intention in this case?
About the intention, well, there is my first post case : AFAIK, there is no way to make the record after inserts or channel redirection have been applied. If needed, we have the input tracks for audio, but no equivalent for MIDI. We could also think of a kind of easy “MIDI render”, for which all eventual MIDI inserts in the track would be applied, thus allowing to get rid of them as well as the initial track.
Not a big deal, though. Thanks for chiming in, Elien…
Rather than trying to do this in real time, the old fashioned ‘bouncing way’, you can freeze tracks in a way that will record the results of inserts and modules. You can freeze it to fresh copies on new tracks, with options to merge or expand by channels, or have it over-wright the original, and so on. Just a little practice required to master it
Having said that, don’t get rid of your virtual ports. Those will come in handy if you want to drive Generic Remote Devices via MIDI track
The Freeze MIDI modifiers is another option that I never used until now : I only more or less knew that it was existing, but never felt the need to look at it more closely. I just did, experimenting with the Tranpose one and it indeed works as expected. So, Thanks !
OTOH, I’m not sure that I got your second point : I have two Generic Remote definitions (one for each of my MIDI controllers) and they are working nicely, here, without any virtual port or MIDI track…
If you want to ‘record’ your controller movements in a MIDI track you can:
Make a MIDI track.
Set the input of the MIDI track to be your controller(s).
Set the MIDI output to be your virtual port, channel to ANY.
Set the input of your Generic Remote Device to be your virtual port.
At this point, you can arm the MIDI track and record your controller movements before they go into the remote map. You could also use inserts such as MIDI Transformers and modifiers before sending things on to the remote map if desired. It might also give you some routing options that you didn’t have before when going through a track first, and then into the Remote Map.
Why would you want to do this? Most of the time you won’t, since you can record directly on automation lanes…but there might be times when it comes in handy. One advantage to recording things like this, is that recording to MIDI tracks give you all sorts of nice record cycle options that you just don’t get with VST automation lanes. I.E. Loop a section and do several takes…a new track for each ‘cycle’ using one of the MIDI record modes that automatically does a fresh track on each take, then go through and pick the best take(s) later. You get some interesting editing options through the key and list editors that just do not exist with straight up automation lanes, like using MIDI Logical Editors. Etc. Those MIDI Logical Editors are pretty powerful…can save a lot of time for things like scaling and shifting CC events around. Yes…you get a lot interesting power tools to EDIT your CC events after the fact as well.
I do it pretty often myself, and later freeze it into the VST Lanes with a write pass in real time at a later stage of the project. Perhaps one of my biggest reasons, is that I sometimes just prefer to open the in-place key editor, pop open some CC Lanes, and draw stuff in with the mouse, as opposed to real time working with controllers. To me it’s a little easier to do mouse work with than those VST automation lanes.
It’s more clear now : indeed, a lot of things become possible using a virtual port this way, to control VSTis. I use sometimes the input transformer, but that’s about all, concerning instruments, I admit. So, I’ll have to look more closely at all this also.
The fact is that I almost exclusively use both my controllers for handling quickly Cubase itself, putting aside the MPD32 drum pads (used with GA or BFD2) : the endless knobs are great for zooming and scrolling tasks, among others (even if the NRPN implementation of the Generic Remote definitions have never worked, here - I found a reliable workaround since a long time for them).
I understand the need now. In the past I suggested to allow all “signals” in Cubase to be routed in an analoguous way, iow. Midi, Automation, Audio - of course all within its own “family” /“Type” of signal. This would lead to midi groups, midi fx channels, etc. etc.
