well, this is a problem what I have in Nuendo & Cubase in various versions, so I think I just ask here…
I usually work on a couple of projects simultaneously - set up very different - some mixes, a mastering here and there, a big recording session etc… And after I reopen a previous saved session I usually have to reconnect the controlroom manually. Of course I use presets for that, but what is causing that?
It seems that the controlroom is not saved inside a project. Or not?
Somewhat anoying because often I forget and then the artist tells me “I can hear the music but less loud then I can hear you”. … Me putting up the fader… “better”? “Well… no!” “Mhh?” Ha, and what happened was that the artist was hearing the music just via my talkback mic which is routed via Cuemix…
Open a project with for example 4 Controlroom Outs and 2 Asio-Outs. Close it.
Open a project with 6 Asio Outs - which are using some of the Controlroom Outs from that other project. Close it.
Reopen Project 1 - you have to reassign all Controlroom outs.
Ya it doesn’t make sense. The preferences should be a global setting to start, but if you change it when doing a new project it should be saved with the project.
Control Room is global should not be saved with the project. This is your global set up for monitoring all sessions that pass through your DAW so you can easily open up any other session and still have your control room monitoring things as you would expect. Think of it like the control room section on a mixing desk - you wouldn’t re patch this every single time depending on the project, and if you received a session from somewhere else you’d like to know that the audio you hear is not due to routing changes on your control room section.
If you find yourself having to change the connections so much then either look at using presets (you are) or rework your template files so they take into account your various working methods before they hit the control room.
And name/organize your channels/configurations.
When you keep the normal “out”, “in”, “HDSP MADI 1”, there is a chance that your system gets confused when loading a project from another studio, using the same default names.
We are exhanging projects between 6 systems, a few dozen times a day, and we never had any problem with re-assigning in’s and out’s. When we load a project where no “PSX100_L” input exists, it defaults to “something else”; when all the systems have a “PSX100_L” input (no matter what channel this is assigned to), it always load perfectly. So when you open a project from another studio, where “out” was channels 7&8, then these “out” buss will load channels 7&8, even though you have assigned channels 1&2 to them.
And of course, when you have assigned an external FX to channels 7&8, they will be re-assigned too, because they were “stolen” by the project you just tried to load.
It actually makes sense, it’s a matter of organizing and labeling your stuff.
I commonly use stems. To monitor these, I activate the outputs as monitor sources on the Control Room. Whenever I load a project, the last monitor source button is always off, regardless of the state it was left in when project was saved. That’s one odd thing, probably a minor bug.
Also, if I create a new project, and create the stem outputs I need, the control room completely forgets I had any outputs monitored at all and they are deleted form the control room setup, even if I load it from a saved CR setup. The outputs are definitely consistently named, as the output configuration is also loaded from a saved output config. As I say, re-loading a previously saved CR config (in VST connections) does not bring back the monitor outs.
It’s as if, on initialising a blank project, control room sees that (at this stage) there is only the single stereo output, and wipes itself of all output monitor buttons. Even when I then create the outputs in VST connections (using a saved setup as I mention) control room does not intelligently realise this. It had permanently lost the monitor outs - IN THAT PROJECT. Go to another correctly working project and it’s all back to normal. Quite odd if you consider that CR should be SYSTEM WIDE (which is how I think it should be BTW).