If you solo/mute a Group channel in the mixer (e.g. the Song Group) then the solo/mute setting is cascaded to everything it contains. If you then go to one of the affected items and try to change its solo/ mute VSTL gets “confused”.
I would much rather see the mixer behave like a hardware mixer in this respect.
Musicullum
As for Solo/Mute a Group: for Mute, that may be true (sufficient to mute a Group, for instance) but not for Solo; the Groups’ “children” need to stay unmuted - and that is true for a hardware mixer as well, no?
Maybe a solution would be to have a dedicated “headphone” channel and allow the user to decide where it outputs.
This would allow solo of a channel without affecting the main mix. For those who like it as is then a preference setting or a button on the “headphone” channel maybe to mute the main out on solo.
My ignorance maybe but on the Behringer X series they say Solo “routes the currently selected channel to the monitoring paths” which is the way I’ve always used it.
In a live scenario solo would appear to be dangerous otherwise.
You are perfectly right, but the terms are usually used like so. Of course, it is different for Studio and Live use. But for said function, there is the term PFL, which explicitly routes the pfl activated signal to a dedicated output. A “Solo” button on pretty much every mixer channel does exactly that, it mutes all other channels (except Group children).
One more query - if I solo a Group and its sub-channels also show solo what am I actually hearing? The Group or Group + sub-channels (which is sonically different)? Or does the sub-channel solo just indicate it’s being soloed somewhere higher up the chain which is where the confusion arises. Maybe a different colour of the solo button if its part of a soloed group?
Here’s an idea: a menu to select a channel as “Listen Channel”. When enabled, Solo works like a regular “Listen” function in that it sends “soloed” channels to said selected channel, and Solo is “blocked” at the same time - killing two birds with one stone?
I was trying to differentiate between live and programming/setup uses. In a live scenario soloing would be a problem if done (accidentally?) while a song is playing. If solo goes to another output, as you suggested, then this problem goes away without the need for lockout.
I do think my idea changing the colour of channel solo buttons when the group is soloed is a good one because you then have an indication of why the channels were showing solo in the first place. That was the problem I saw on a remote session - the user did not know that the group had been soloed so couldn’t understand the changed behaviour of solo/mute in channel view.