I do understand what you’re asking for, but as Steinberg seems to be focused on really needed things like being able to view the interface in Klingon, for some reason, a 3rd party program might get you closer to where you want to be before you get something like this.
I know people can get into different programs’ guts via scripting on the mac, so it goes beyond just keyboard presses and clicks.
The forums are where dreams come to die, after all.
I can already get close, or all the way, by combining AHK and MIDI Remote API scripting. But this route is very opposite of user friendly. It requires decent skills in two programming languages and 2 3rd party applications.
Not when we’re talking about interfacing with Cubase. It would require Steinberg to release an API for the application itself, which I can’t see happening ever. Unless you have concrete examples, you just have to trust me on this one.
I’m happy to discuss this further, but this isn’t the thread for it. Shoot me a PM if you like.
New version - render and clear plug-ins. One click in-place rendering which is reversible.
New version - bounce track. Rather than bounce selection, bounce the whole track while having access to the original if a week down the line you realise you messed up a comp.
New track type: Combined Folder & Group Track
Ie. a folder track that has its own audio channel. Any track that is inside such a folder will be routed automatically to the Folder&Group channel.
MIDI Remote + MIDI 2.0:
When I attach a MIDI 2.0 Controller to the system I would like Cubase to generate the remote surface automatically for me, so that I only need to map those items to Cubase functions.
Node based VST Parameter generators and transformers with a user interface similar to Fusion in DaVinci Resolve.
This would allow function generators and modulators to seamlessly connect to MIDI ports, MIDI remote, MIDI/Instrument tracks and output to any VST plugin parameter or MIDI destination.
Make the Automation Event Editor function exactly like it’s counter part in the Key Editor does.
Bring FlexPhraser to the forefront and begin adding more capabilities to it.
A feature might be something like a randomly-generated guitar strum, in a certain style, or a bass pattern that can be generated based on a drum beat.
Attach the studio setup to project rather than globally to Cubase.
This would allow in Windows to use different audio interfaces/cabling dedicated to project type.
Actually when I switch to my guitar dedicated audio interface for recording, connected to my guitar amps and my effects in the FX loop (setup which I dont want when recording synths or percussions) , I have to rebuild all studio setup. Even with presets (do they work?) something has to be changed each time I switch my project.
A studio setup doesn’t move that much, IMO, and I don’t want each time I load a project to bother about the audio interface driver and routing. Granted, I have only one audio/MIDI interface at disposal, so YMMV, as usual…
Additionaly, I think that it would significantly increase the .cpr file size of each project saved.
I never have this kind of issue : I use a fixed studio setup and use a general template with all my instruments/tracks available and correctly routed when I start a project : I just remove gradually what I know won’t be used, during the ‘in progress’ stage.
So if you have only one setup and one audio interface, I don’t see what is puzzling you in the way/emplacement this information is stored by Cubase, because you never change your setup.
No personal experience I can offer here, sorry. All I can say is the presets in the Studio Setup dialog window, should be the (slightly ‘clunky’) solution to manage the exact situation you describe.
From memory, loading a project and then changing Studio Setup via a preset is not the way to go - this won’t always catch and correctly set up all the specific routing/connections that project expects/needs… i.e. you will have to go in deep and fine tune those manually. Which is tedious.
And as such, your bigger point requesting Studio Setup configurations be saved/loaded on a per project basis, rather than remain as global Cubase settings, is a perfectly good one. And I agree.
Mind, I remember this has been asked for many times over the years - there has to be some huge, underlying architectural reason why this has never been accommodated, since for ever… hence the ‘presets’… they should be of help.!