Yeah, that’s a weird thing about this forum. Apparently just reading a bunch of different topics will increase the privileges you’re allowed.
(that’s an antispam function.)
Pretty much works.
One problem with using the track mute method is with 3+ keyboards there’s a bunch of redundant instruments to keep track of.
Unfortunately I see no way to use Generic Remote (or any other method) to specifically select a track number.
What do you think about using MIDI transformer (I’m just reading about this) to convert a ‘program change’ message (from a MIDI track looped back to the input) to change the incoming channel - if each instrument were set to a different input MIDI channel this would allow multiple MIDI keyboards to access different instrument tracks at programmed song points during playback. Is this feasible?
The transform function would need to make a track change its input MIDI channel into something else. There may also need to be a MIDI merge function somewhere it that path to merge the MIDI track with the input channel to the track - unless that can be made part of the MIDI transformer as well.
This is assuming the Transformer operates in front of the MIDI channel assigned to the instrument track. So all instruments would be set to use All MIDI Inputs and all of my external MIDI controllers would be set to different channels.
While a common misconception, this doesn’t occur - Track’s do not listen to a specific MIDI Channel. The MIDI Channel setting on a Track controls the MIDI Data that the Track transmits. For example, say you have a Track with a MIDI Part and the Part has some Notes on Channel 1 and the rest on Channel 2. If you set the MIDI Channel on that Track to Channel 1 it will play all the notes in the Part back on Channel 1 - regardless of the Note’s Channel. But if you set the Track’s MIDI to “Any” it would play the Channel 1 notes back on Channel 1 and 2 on Channel 2. And if it is set to Channel 4 all the Notes will be sent on that.
The way to limit what Channel(s) a Track is listening to is to use the Input Transformer. Which can be automated.
I don’t really follow along on this as it is dependent on your specific setup and use case neither of which have been well defined. So any recommendations are based on a generalized case. One thing I’m pretty sure is that the solution is probably way less complicated than your current approach.
Can you give a more detailed description of how your different keyboards are integrated into Cubase. What MIDI Channels are they transmitting on? What is each Keyboard’s purpose and what does it need to change under what circumstances? What do you want to happen and what are you keen to avoid happening? Anything else that matters? You might find some of that is easier to describe with a sketch or chart.
Describe the end state you want & not how you think the road to get there should be built.
You’re probably right about the complexity, so I am going to start off your way. It’ll be good to learn Cubase. I design space-based earth-orbiting synthetic aperture RADAR digital processing boards, I have an extremely bad habit of making things overly complicated.
Raino, so I have 3 USB MIDI keyboards and 1 DIN MIDI foot (bass pedals)controller for this setup. I also just got a pretty sophisticated MIDI foot switch box that’s very programmable. I trained for years to be hand independent. I can literally switch from the 3rd keyboard on the tier to the 2nd keyboard within 1/8 note. For a very long intro (progressive rock) I will use 4 sounds. I am also trying to incorporate guitar articulations (Orange Tree Samples) so there’s more work.
When I switch my hands from the 3rd tier to the second tier, I often do it to free up the 3rd tier to change the sound, maybe for the next section - B-3 organ to strings in the current case. Usually I don’t ever have both hands on any 1 MIDI keyboard unless I am doing it to free up another controller for a sound change.
So my song starts Bass on Tier 1, Guitar chords on Tier 2, Organ on Tier 3. Several bars into the song Tier 2 needs to switch to lead guitar. Tier 1 doesn’t change that much.
The bottom 2 keyboards are 88-key. I know I could have multiple sounds by splitting, but that just doesn’t seem to work very well for me. While playing it is important for me to have my hands in non-crossed over position, etc. and also when I am making a fast move from tier 2 to 3, for example, having the keyboard split means a bit of lateral movement in addition to the vertical. The lateral is quite a bit harder for me to locate than vertical.
Expanding this, I actually have much more equipemnt than this, but I want to play Yes Siberean Khatru on just these 3 keyboards and bass pedals. It is much easier with 6 keyboards but they just take up so much room.
Not sure if this will help but I once had a situation where I wanted to emulate pipe organ stops.
The idea is to keep a folder full of MIDI tracks at the very top of the project to serve as ‘MIDI router’ central.
I arranged it so the 16 MPC pads on my MPK2 toggled ‘on/off’. These were diverted straight into a Generic Remote, which in turn toggles to arm/disarm track 'Monitor" for the first 16 tracks in a project. If I wanted I could swap Generic Remotes for one that arms/disarms ‘Record’ instead.
Example Project:
MPK2 Organ Stop Example.zip (328.6 KB)
I kept 16 Empty MIDI tracks at the top of the project in a folder that served as routers to my ‘organ ranks’. (I could optionally arm them to record stuff rather than just ‘monitor’ if desired).
Note, if the Organ Stop concept isn’t a good one, you could build something similar that works with program or CC changes if preferred. I.E. A given PC might launch a macro to Arm 3 tracks and disarm 2 others.
I could then easily toggle any combination of the 16 ranks I wanted from the MPC pads. Lit up pad, that channel is broadcasting (track monitoring enabled). Not lit, the track is quiet.
For automating more advanced stuff that doesn’t have automation lanes of their own, I set up a virtual MIDI port. MIDI Track > Virtual Port > Generic Remote. The advantage here is that one can automate more things in the DAW as part of the sequence that don’t have native VST automation lanes or special track types. I.E. Toggle track controls like Monitor/Record, stopping the transport automatically at the end of a sequence, launching macros, moving the loop points and cursor around. Using MIDI Transformers and insert effects on automation lanes. Etc. Automation can be drawn and/or recorded on a MIDI track. One advantage to keeping this stuff in MIDI tracks is the MIDI Logical Editors work, as does retrospective recording, cycle recording with ‘multiple versions’, and more - stuff that we simply don’t get with the VST automation lanes.
Wow, Brian, that’s cool! The generic remote didn’t load with the project, but then I realized that it’s not project based.
It’s too bad that there’s no way (unless I’m mistaken) of using the generic remote to navigate to a specific track number - only relative up/down navigation.
Launch Macros that launch Project Logical Editors. You’ll take advantage of how you ‘name tracks’ to zoom in on which ones to manipulate.
You can use Project Logical editors to manipulate the Folder/Track order. Select tracks by name, rename tracks, position the cursor and loop points, and a whole lot more. Nests of folders can be helpful as well.
First make a new Generic Remote, then ‘import’ the xml files.
With the MPK2 I actually stack 2 different maps. The smaller one just duplicates the transport controls in case I have the ‘common’ channel of the controller sending over the B port rather than the A port.
Natrually you’ll have to move things around to fit whatever MIDI controllers you use, but having a glance at them might give some ideas. It’d show how I’ve got those MPC pads set up to ‘daw commands’ like arming and disarming the ‘Monitor’ control.
Main thing to remember with Generic Remote stuff is that track or plugin instance order matters with a lot of things! Some things you’ll have to be pretty careful about never changing the order of the tracks (unless you intend to swap the control sets as well).
When you bind controls to ‘plugins’ via Generic Maps, it goes by plugin name, then instance order I think.
It just takes a little practice to get some idea of how things work with Generic Maps. The good news is that it’s not hard to keep the map open and change stuff on the fly if needed 
Also, don’t forget you can STACK maps, and have more than one. In fact, if you want a single control to do multiple things at once (I.E. CC55 on Channel 1 to tweak TWO parameters on two different instruments/tracks in one go), you MUST stack maps. If you try to list the same control twice in the same map, it’ll only trigger the first event down the list and ignore the duplicates further down.
Generic Remote Management…
It’s possible to use ‘presets’ inside a Generic Remote to change things on the fly (you can remote control changing the presets too).
Personally, I have lots of the things…but rarely have more than 2 or 3 ‘connected’ to anything at once. Want a Generic Remote map to stop doing anything? Just disconnect the Input. So, don’t be afraid to have lots of them as you’re experimenting and trying different concepts. You can always just ‘disconnect/reconnect’ the one(s) you want to work with.
Since you don’t need to switch between sounds on the fly that simplifies things and lets us use basic Automation. Here’s how I’d set that up (not that I’d ever attempt to actually play multiple keyboards at once).
First I would not use “All MIDI Inputs” as the MIDI In for any of these Tracks. Instead use the individual MIDI In from the controller. Let’s call those Tier3-In, Tier2-In & Tier1-In.
For each of the sounds you want the Tier3 keyboard to play create an Instrument Track that will play just that sound. Set the MIDI Input for all these Tracks to Tier3-In. While not necessary to functioning, putting all these Tracks in their own Folder will help keep things organized. At this point if you Enable the Monitor on all the Tracks and play the keyboard you should hear all the sounds stacked (careful, don’t set off an underwater volcano). Now on each Track record or hand edit the Automation (like above) for the Monitor Control to set which Track(s) can be played at what times. Mute would work too, but I think Monitor is better. Mute stops the audio coming out of the VSTi while Monitor controls whether the VSTi is receiving MIDI or not.
Repeat for Tiers 1 & 2.
If there is a sound you want to appear on multiple keyboards use a separate Track for each one.
You don’t need to navigate to different Tracks for this to work.
I had in mind a live gig.
Send a remote event from a Master Controller. Generic Remote picks it up, launches a macro that disarms the top folder full of tracks (Project Logical Editor), Finds the folder you want, moves it to the top of the list and arms everything in the folder. Optionally, it can move the play-head to the next song in the set.
You can have an entire set of songs in one project. Send a Program Change and boom…sounds ready, play-head on the next song, all ready to go. You could also set-up to arm for recording rather than monitoring, and record what you do in your gigs 
As for changes that happen in the middle of the song, same general idea, but the stuff will already be at the top of the project. This concept can also keep a common set of DAW Level MIDI Controller faders/pots mapped across whatever instruments are up top if you need them. If you’re playing ‘with a sequence’ you can go ahead and ‘automate’ your instrument and controller changes (either on VST lanes, or via MIDI Track > Virtual Port > Generic Remote). Or if it’s a more ‘free-flowing’ song with little or no sequenced stuff…call it all up with a MIDI event from one of your Controllers.
While you’re at it, if your gig uses any sequenced material, set up a MIDI track that’s dedicated to Transport Stops. Direct that into a Virtual Port > Generic Remote that listens for transport controls. Now you have a way to make each song in your set automatically stop the DAW transport at the end of the song. If you know the set order, you could also have that track go ahead and launch the Macros/Logic Editors to set up the next song automatically.
Gist of it is: Study how the Project Logical Editors work. Once you’ve mastered using that to find and select folders/tracks, move them around, etc…
From there read up on Macros. How to build those and bind them to keys and stuff.
Finally, experiment with Generic Maps, as these will give you a way to launch those Macros with buttons or keys on your MIDI controller(s).
Maybe I can throw together an example set to study. I should have some around from years ago when I did more live playing. Hang tight…will see what I can dig up.
As I understand, it is a live gig but some of the parts will be played by pre-recorded Tracks in Cubase. So the whole live performance is ‘synced’ to the Cubase Timeline - including when the sounds changes occur.
That said, a Generic Remote approach, while overkill for this specific situation, is great info that I’m sure will be useful to many folks who come across this thread.
1 Like
Okay, raino, I get it, I will try this method. I like that the instruments won’t see any MIDI input using the Monitor control so no processing overhead. I will also have programmed drums and other accompaniment and will freeze those tracks.
It will take some time.
Wow, Brian I have a lot to learn - ‘Project Logical Editor’ I need to spend some time messing with Cubase, I realize. I just now figued out I needed to set up the missing Presets in the Input Transformer.
I am going to read and re-read you post, you’ve given me a lot to study!
Good news is that I’ve cobbled together a simple demo project and it’s working well. It supports a set of up to 9 songs.
Bad news is that it’ll take me some time to work up documentation on how it all works. I’ll get it posted as soon as I get some time to build some kind of tutorial and explanation/documentation to go with it. Here’s a basic overview of what it’ll do.
I’ve loaded 5 songs into a Cubase project, all along a timeline with some bars space between songs. I used a Marker track to set the start of each song. I also set cycle markers (more on why later).
I’ve Nested each ‘song’ into its own folder. The top level of the song should begin with a song number in parenthesis. I.E.
(1)Birdland
(2)All Of Me
(3) Anthropology
etc…
I’ve built in support for 3 controllers, at this point, but it’s easy to add more (Nest tracks in folders for weird combinations, or extend the macros if you need even more). Any tracks that need to be armed/disarmed via remote, or upon selecting the song, I just use ~a, ~b, or ~c somewhere in the track/folder name.
I use combinations of Macros and Project Logical Editors to stop the transport if it’s going, hide and disarm everything but the ‘current song’, snap the cursor to the beginning of the song of choice, set the locators around the song, and zoom in or out to a state (zoom to cycle markers) where the full song structure is visible.
I.E. Tap ctrl-alt-1 and song one is ready to go. Tap ctrl-alt-4 and it hides whatever song is up and shows song 4. Etc. Tap ctrl-alt-0 and the project leaves song mode and everything is visible again.
I’ve also included a Generic Remote that allows calling up songs via program change. There are also some bottom octave key-switches that can arm/disarm (toggle style) visible tracks with ~a, ~b, or ~c in their name via remote.
I.E. Tap MIDI note 0 (C-2) on your MIDI keyboard, and all your ~a tracks get the Monitor state toggled. Tap the next key (C#-2) and ~b tracks toggle, etc. Similar mapping is done to toggle record for tracks as well.
Optionally, one can use a virtual MIDI port, and keep a MIDI track in each song that can automate launching these (or other) macros (or whatever you care to bind in any Generic Remotes you have listening to the track). This would make it possible to do things like toggle armed states of your live tracks, stop the transport automatically, and jump to the whatever song in the project you want next (If your gig has a set song order).
Of course you can tweak and ADD features all you like.
So, with a single key-combo, or the tap of a MIDI controller, you can instantly manage a play-list of up to 9 songs in a single project!
It’s probably possible to get more than 9 songs, but I’ll have to study up on if the macros and such are capable of swapping out marker tracks, or swapping between multiple loaded projects.
Wow, Brian, that is so much work, I hope many here can learn from it. I have 2 Cubase setups (and move the USB elicenser from one to another, that is a bit of a pain, and don’t run Cubase on my laptop as it only has USB-C ports.
So I have one PC that is where I work, 3 4k 43" monitors, etc. and then another room with the musical equipment where it is much less conducive to anything other than playing - with the 3 keyboards etc. the micro keyboard is awkwardly placed, as is the trackball.
I have to figure out a way to make aliases since the name of the keyboard I have at my desk - Keystation-61 - does not match what I have when really playing - A88, KK88, KK61. Not a major obstacle, I could write the song out using Keystation-61 then edit the sources. In this case I wrote this at the 3 keyboard tiers and it shows the correct assignment, when I run this at the 3 keyboards it will pick it up:
I’m trying to figure out how this information is stored. A lot of little hurdles like this.
Aside from removing/redirecting missing links at start-up, or in Audo Connections and Studio Setup/MIDI, I’m not aware of a way to change this inside Cubase specifically other than simply changing it on the track inspector to something else.
In some cases instruments can be bound to MIDI Device profiles, and also to a given set of Audio outputs. That stuff is done in Audio Connections (F4), and in Studio Setup.
In short, each time you migrate the project from one system to another, you’ll need to change the links for any devices and plugins Cubase can’t find on the new system.
Also be advised that some things about your Cubase setup is NOT saved with project files at all. Cubase global preferences, presets, etc…all this stuff is ‘system independent’. Thus, anything you want duplicated across multiple systems needs to be imported into them. I.E. Generic Remotes, Key Commands, Logical Editor presets, and more. Pretty much everything in these directories:
%APPDATA%\Steinberg\Cubase 11_64\Presets
And possibly (user stored plugin presets that might be of interest)
%USERPROFILE%\Documents\VST XMLs
%USERPROFILE%\Documents\VST3 Presets
%USERPROFILE%\Documents\VSTConnect
%USERPROFILE%\Documents\VSTTransit
CPR files don’t keep up with the DAW globals. They just store the actual project information, what plugins to hook up (by id), and device names (as they were on the system you saved it).
If you open a project in system with different devices and such…Cubase pops up dialogs where you can either swap to something that does exist, get rid of the reference, or leave it there as a disabled device to change manually later (See Audio Connections [F4] and Studio Setup/MIDI Port Setup in Cubase).
Recommendations?
To get a project from one computer to the other.
- Always do a ‘project backup’ of the project you’ll be moving to another PC rather than just copying the project directory. It’s also important to do use ‘backup’ anytime you want to MOVE a project to a different drive, partition, or directory on the same PC! This clears the ‘path’ information to the project’s media-pool so next time the project gets launched Cubase can restore any path changes to your media-pool. It’s a good idea to keep a copy of anything and everything a project uses somewhere in the same Project directory (these will have to be copied manually to backup copies).
Example: User begins a project in a directory named “Married To a Tramp”.
A few days later the user decides to use Windows explorer to duplicate the “Married to A Tramp” folder at the same folder level, but renamed to “Divorced from a Tramp”. Later the user wonders why he opens the cpr in “Divorced From A Tramp”, but the stupid thing is still using the media pool in the “Married To a Tramp” folder! He’s got a potential MESS on his hands if he keeps up with habit of renaming/moving things.
To avoid such issues, do the duplication instead from inside Cubase via File/Backup Project… (read this link carefully, practice with it a bit with a trash-test project until you understand exactly what it does…know it well) .
I.E. Unless all your systems have a near mirror storage structure, It can be a problem if you just copy a project directly from one computer to another. Cubase doesn’t have a way to manually change the path to a specific file in the media-pool. Supposedly if Cubase can’t find a file you were using it’ll pop up a dialoge asking where it is? At first it doesn’t seem like much of a problem since Cubase will ask about ‘missing files/devices’. Still, it can lead to long term issues if you just copy a project folder from one location to another directly and try to use it (scenario above, Cubase finds files, but they’re not living where you intended! Worse yet, it might try to over-write something unintended!). So, get in a habit of using File/Backup Project… for anything you wish to migrate to a different machine, archive to deep sleepy storage, or share with others.
- After importing a project made on some other machine, you’ll always need to make any adjustments pertaining to the hardware for that system and save a new copy of the project there. In some cases just moving a project on the same PC might even lead Cubase to ask questions about ‘missing files’. It won’t hurt to get in a habit of somehow notating in the project name what system saved a given copy.
I.E. I have a computer named IMP, and one named STORMTROOPER. So whenever I start on a new project I’ll include IMP or STO somewhere in the project name. If I import something done on a different machine, I’ll do save-as and start a working copy of the project (cpr) to reflect the system that made the file. The project name now includes a reminder of what PC that copy of the file was made with. “My Kick Ass Project - Rev 1.0 IMP”.
Don’t be afraid to fork-off as many cpr files you need/want. Use the note-pad in Cubase if you want to add any project notes on when/why you’ve forked to a main/current *.cpr. The cpr files don’t take much relative disk-space (a cpr is mostly pointers to the larger media files and plugins involved in the project)…
I also advise putting some kind of text or word file in the project directory to store any notes and comments about the project. That might include a copy/paste of your Cubase note pad, plus any other notes you want to make. Getting in this habit before putting a project away for longer than a few days will be a life-saver in the long run! Months from now when you’re wondering what’s on that hard drive, you’ll have your text notes for a quick and easy glance as to what’s in that directory and how it all ties together! In short, if you can, keep a little ‘running history’ of anything you think ‘needs to be remembered’ about the project months or years on down the road.
It’s also a good idea to export essential Generic Maps, Drum Maps, Key Command presets, and other ‘global’ Cubase preferences into a sub directory of your project. You might even build a one click script that just zips the entire %APPDATA%/Steinberg/Cubase 11_64 directory off your system desktop that you can name accordingly and move the project directory. You should keep a separate archive for each machine involved. You might never need those pref zips, but if you ever do, they’ll be there!
P.S.
If you want a way to have a set of universal MIDI Devices across different systems, you could install a virtual port driver, and use something like Bidule or Bome to route real devices to a common setup.
I.E.
All systems running loopMIDI with virtual ports named.
Controller A (Virtual ports for all of your MIDI controllers)
Controller B
Controller C
Controller D
MTC (for timecode if you need that)
loop1
loop2 (Set up as many loop-backs as you’ll need. I.E. for routing a MIDI track > Generic Remote)
All systems running a Bidule instance that redirects the actual devices into the virtual ports with your universal naming schemes.
Actual device > Controller A
Actual device > Controller B
Actual device > Controller C
Actual device > Controller D
Under this scenario, Even if you don’t have the actual device plugged in and routed with Bidule/Bome, Cubase would still find ports with all those Virtual Port names on both systems.
You’d use Bidule/Bome to route real stuff into the virtual stuff as required.
Something like Bidule or Bome would also give you a plethora of extra controller switching and real time transformation options well before anything even makes it into Cubase!
Bidule can also do the same thing for audio if you add ASIO Link Pro to the mix.
So, in theory, you could use:
loopMIDI
ASIO Link Pro
Bidule
And get a universal audio/midi layout across systems that should just work right away when importing Cubase Projects back and forth.
Bidule and ASIO Link Pro would serve as your ‘patch bays’ for routing everything into or out of Cubase.
In some ways it might add more complexity than it’s worth. Simplicity VS Flexibility. In most cases it’s probably best to just let Cubase ask about the missing stuff at project launch and deal with it then; however, if you want uber flexibility and a way to build SUPER CONTROLLER setups across multiple systems (you could even set up an OSC Server in Bidule to tie in a wireless tablet or phone), then check out those apps!
Oh, and if you want to tie the laptop, tablets, phones, and desktop together in the studio…
ASIO Link Pro has you covered on audio over ethernet!
For the MIDI side check out rtpMIDI (MIDI over LAN/WAN). The free ReaStream plugin might also be of interest.