Same problem here Steve. Plus I had to redo all my workspaces because of the new mixconsole, and after all that they don’t work. It is for this reason, and various graphic and UI issues that I’ve gone back to 6.5 and couldn’t be happier.
There seems to be be a general misunderstanding of how people work in studios at steinberg.
The new mixer is just example.
Steinberg seems to think in general that it’s useful to have things stored with the project that should be saved generally:
VST Connections. Those are related to Hardware. When I work with my desktop PC in my studio I will always have the same hardware installed, because it’s, err, hardware. When I work with my laptop I have other hardware installed. So it makes no sense to store the audio hardware configuration with the project as soon as I work on it with different machines. It also makes no sense when I don’t, btw.
What makes it even more complicated is that control room setting are saved, as it should be, generally. But: they refer to same installed hardware ports, so there are conflicts every time I load a project with other settings.
Workspaces are related to hardware too. At my Desktop I have a different display situation than on my Desktop. See above.
I can imagine several situations (and experienced them) where saving audio and display setting (such as workspaces) globally makes sense. For instance when loading older projects after I bought a new display or soundcard. I can’t imagine a single situation where it could be useful to have them stored individually with every project.
So from my point of view the Mixconsole/Workspace situation is just a detail where a wrong concept is especially wrong. It should be changed generally anyway.
Absolutly agreeing with you on the VST connections : it’s a PITA to have them project dependent. Fortunately, there is the solution to save them in a template, but still… I’m glad that I don’t have the need to change them from my DAW to another system.
I would be more balanced, though, about the Workspaces, as they can be stored as ‘Global’, making them act as a possible kind of ‘Workspace template’. I use them often this way, by locking them until I pass the ones needed to the left in the ‘Organize workspaces’ window, unlocking them at this stage.
I have a myrriad of different scenarios for varying project types. Simple example, I might want to record one artist or two artists for which I may need 1 or 2 que sends resp.
Once recorded however, I no longer need the cues, so I might convert these to aux sends or something else. This would indeed be a PITA if e.g. the settings for VST connections were not Project based.
This can’t be a hard feature to implement, they already have the code written for it (as it saves to project file). Why not just import/export to an XML file or something? It’s absence is making things painful.
+1, though i like to have the option of both global and project-based workspaces. as someone suggested above, i will most often start by importing the global ones, then adjust them for a specific need of a project, eg. adjusting a workspace to display and arrange the GUIs of certain plugins that may only be inserted in that one project etc. the presets should just be able to include in them all the settings of the displayed mixers.