Setting Focus to mixer window - how?

Hi you many thanks :slight_smile:
I have the german version and it is simply “nach vorne”… how obvious… sometimes I can be oh so blind.

Thx a lot!

Yes, that’s it! :slight_smile:

Ah, if only I could count the times that I was certain I was searching for the correct command… :see_no_evil:

If the key commands window had a search like the new MIDI remote mapping assistant… That would be the bomb! I think it’s just a matter of time.

1 Like

Hi, I use/sacrifice Mixer 3 (and in Cubase 12 Mixer 4) for my macros.

That way I do not have to worry about the Main Mixer Window being open or not when I trigger macros.

The Mixer you choose to use for the macro should not be used for any thing else other then the macro in your normal workflow.

Example of how I program a macro when I need the mixer to be focused for it to work.

German Macro

EN Macro

I used this a while back to solve an issue I had with bypassing Inserts on selected channels.

If you are interested, you can read more about it here.

Workaround to Bypass Inserts, Sends, Channel Strip, EQ and Cue Sends with short key

Maybe this is of use to you.

2 Likes

Thanks to both of you. Your ideas have helped greatly.

I think I finally have something that works, albeit that it leaves focus on the mixer after invocation. This combination ensures that the mixer doesn’t get closed if it is already open.
Project => Bring To Front
Devices => Mixer
Channel & Track visibility => Visibility Configuration x

Great that it helps.

I wish Steinberg would realize that (key)-commands NEVER should depend on any focus. All commands should be allowed at any time (no matter of focus) plus all commands definitely have to work state-unaware.

5 Likes

I could not agree more.

Exactly!!

  • 1

I disagree.

…because? :slight_smile:
Of course state intedependence (which also means focus-independence) would limit the number of possible different commands assigned to keys simultanuously which is an obvious disadvantage.
A possible solution - which would very easy to implement for steinberg - would be to include commands that allow to focus ALL windows individually. So those who need focus-independence could set up macros in the way “fokusxy + desiredcommand”.
The minimum we should expect is that the commands carry out one single action - independent from context. IN that respect the F3 - show mixer - is just stupid because it does 3 things depending on state (namely “open”, “focus” and “close”).
The point is: The way some of these things are implemented currently is only reasonable if we have a picture of a keycommand user in mind that always uses them only when a certain window is in focus already. For some commands this scenario is absolutely logical. For other commands it is not.

While your more recent post is more nuanced, it’s still pretty adversarial and imho misses out on a pretty substantial aspects: different use cases, historical evolution and backwards compatibility.

This still sounds rather absolutist and not cognizant how things may make more sense in a different context than the one you’re thinking of.

In a world before macros and before remote control were added to Cubase, that 2 way toggle (with an implicit dual initial action), isn’t unreasonable - it’s actually quite useful. And I assume, many Cubase users are still using it exactly in that original context without macros and remote control.

So the current implementation isn’t stupid.

That being said, I’m also deeply into midi remote control and scripting, and I also wish I could remote control the mixer window better than is available now (and a whole number of other Cubase actions).

Of course you can choose the tone of your communication any which way you wish, but if you’d express your quite reasonable desire for better handling of that (and several other) Cubase Key Commands in the form of one ore more properly tagged and nuanced feature request rather than a flaming rant, you might have a much better chance to get support from fellow users like me.

Hi you,

thank you for your feedback (even though it feels a little bit like a rant against me personally), I really appriciate it. My posting was not meant to be a rant at all -but I do understand that it can be read this way. So this I am sorry for. To a degree it is about using a foreign language (which English is for me) - to a degree it is about writing rather than talking and the resulting missing nuances. “Stupid” e.g. is not a strong word for me - but as I said: I see your poin and your feedback is welcome.
There is a point - I must confess - where I intentinally stand with my criticism - which has to do with the way I see the “evolution” of software engeneering (and the education of software engineers). At the same time I really admire the people who develop and maintain a piece of software like Cubase - especially with regards to its long history.

2 Likes

Not against you - just a little against some of the content of your posts in this thread. :grinning:

However, as you have felt the emotion of someone critiquing your post, imagine the emotion of a team of software developers having their work called stupid.

By the way, your command of the English language is so excellent, that it never crossed my mind, that it might not be your first language.

I agree with you that software needs to evolve. But I also know that the list of things to be improved is incredibly long - especially for Cubase, since I believe it is the most feature rich DAW in the market. This feature richness also creates a significant problem in modernizing. A smaller feature set would be easier to modernize.

There are numerous things that I think can be and should be improved in Cubase for my particular use case. The Cubase/Nuendo development team will probably never be able to catch up with all of those! And they are not perfect. (And neither am I). But they are a very, very good team. And they try really hard to keep evolving Cubase in a way that pleases as many current and future customers as they can. All this while competition in the musical software business is higher than ever before. So their job is not always easy.

But thank you for your overall positive reaction to my post - I appreciate it very much!

Thank you for your kind reaction - you know, feedback (also concerning my “tone”) is welcome and can really help to change a little - especially when maybe some emtions pushes us (which it sometimes does as far as I am concerned).

Having said that: There is a big reason for me to use Cubase which is mainly based on my view upon the team that brings this product forward - yes, no doubt, they are a great team. I also have a “big heart” for those, who work on the evolution of an “old piece of software” - it is so much easier to build something from scratch (most of the newer products simply build upon what has been discovered by the “older teams” - but without technical or conceptual dept). So - no, noone is stupid at Steinberg , while some decisions sometimes feel “stupid” to me. I am thinking a lot about this word - sometimes I think about using “wrong” or “bad” - what I actually want to say that I would have taken a different decision, which is of course easier to read as a personal opinion. I hope that everybody can understand, that for me EVERYTHING someone utters is just a personal opinion - since I usually prefer not to run useless and unproductive “right or wrong” discussions.

Thanks for all your patience when reading my posts! :slight_smile:
BR, Ernst

2 Likes

Never a problem for me.

While Key Commands depend on focus, how would you feel if the Key Command page was completely upgraded, improved and re-designed so that on any page the re-design indicated which focus pages the KC could possibly be functional in? More users mentioning this in the Feature Request Page maybe?

The KC page is very old and needs updating. I have grown weary years ago of clicking through the entire KC page when the search box doesn’t always seem to help. There are many missing KC’s. Sometimes the “tool tips” do not match the KC. There are other additions that could be helpful too.

Also, for any KC that currently has a toggle on/off command, would replacing the toggle function with 2 commands work better? Always a “on” command and another for “off” to satisfy a lot of macro and LE issues?

Actually, utopia would be for both toggle and a “on” and “off” KC, but I’m not sure of the programming issues…

1 Like

Hi … yes :slight_smile:
It would help to have singular “on” and “off” commands alongside with “toggle”.
And a separate “focus” command for everything that can be focussed (or must be focussed to receive key commands).

Cheers, Ernst

2 Likes