Feature Request: Option to unlink MIDI and Audio mute and solo buttons

I've mentioned this before but I don't think it went anywhere...
 
Right now in Sonar, if you have a MIDI track feeding into a VSTi and you mute the VSTi audio track, the MIDI track also gets muted automatically. The problem with this is that if you then unmute the audio track again, the flow of MIDI data would have been interrupted and you could end up with missing notes (since it missed the note-on event), out-of-sync controller data, etc.
 
I think a good way to solve this issue is to have an option to unlink the audio and MIDI mute buttons, so that when you mute an audio track, it doesn't mute the related MIDI track as well. This way, the VSTi keeps getting fed with the correct, uninterrupted stream of MIDI data whether its output is muted or not. Then the instant you unmute it, you will have accurate audio output and no missing notes etc.
 
The same should apply to solo buttons. When soloing an audio track, only the audio outputs of other tracks should be muted, not their MIDI tracks too.
 
To see what this would sound like, play a song that uses MIDI data to drive VSTis. Then while playing back, randomly mute/unmute and solo/unsolo random tracks. You will notice that many times notes will be lost due to the note-on events being missed. Now freeze all tracks and do the same again. See how smooth the mute/solo operations have become now? No more dropped notes or out-of-sync controller data. It can behave exactly the same way if we can only unlink the audio and MIDI track mute and solo buttons.
 
Is there any specific use case where we actually need the MIDI tracks to be muted in addition to the audio tracks? I can't think of any.

Also Ctrl-click doesn't make a difference when muting a folder.

SilkTone
Also Ctrl-click doesn't make a difference when muting a folder.

I think you would want the folder to be a "master" control for everything - enable/disable record, mute, solo, echo input, etc. Otherwise it could get messy with instruments having multiple outputs and multiple MIDI tracks if some audio and/or MIDI tracks within the folder were muted (or soloed) and some weren't. Would the folder button invert the current states, affect only tracks in a certain state, etc. I think the idea of "master" controls at the folder level, with the ability to open it and customize settings within the folder, makes sense.
 
Probably the ideal implementation for you would be:

• All MIDI tracks left running all the time (unless you specifically went in and muted them)
• If you muted an audio track within a folder, it would mute only that track's audio output
• If you muted the folder, it would mute all audio outputs within the folder

I've alerted Noel to this thread in case he has any comments.

>Is there any specific use case where we actually need the MIDI tracks to be muted in addition to the audio tracks? I can't think of any.

Saving of CPU power.

> Alex, mute/solo is not a tool to be used for conserving CPU.


I didn't say it was a tool, I was attempting to answer the question.  I was assuming that if you mute the MIDI track it would stop playing the synth therefore conserving CPU. That would be a valid use case especially in scenarios with lots and lots of tracks. Of course there are other ways of doing it as well...
 
Anyway appears Craig and Noel has explained it pretty clearly thanks.
 
Cheers...
 

Thanks Anderton for the details. I'll be checking out the grouping options. I just never looked at that closely enough for this particular purpose.
 
Alex, but consider this... If you need to mute some tracks just to prevent overloading your CPU, what do you do if you actually want to unmute all of your tracks? Do you pick which tracks are the least important and mute those? How do you listen to the full song?
 
The point is saving CPU cycles by playing musical chairs with mute buttons doesn't make sense because if it gets to that point then your system is seriously overloaded and can't handle the full song. Freezing is a better solution than muting.

Anderton
So, with people running CPU-hungry synths like Diva etc., having "all MIDI all the time" seems like it could be problematic. Of course you could go in and manually mute MIDI tracks to mute the audio and preserve CPU cycles, but then you're just basically duplicating what happens now...or mute only the audio but keep the MIDI data, and pay the CPU penalty.
 
Comments?

Anderton, the amount of CPU you may or may not save by muting a synth is such an unknown. It makes more sense to use the freeze function, which was designed specifically to save memory and CPU resources. Having to mute tracks to prevent glitching also has the big disadvantage that, well, you can no longer hear the track, but you were forced to mute it because you ran out of CPU cycles.

Anderton,
 
I still maintain that mute/solo buttons should not play the role of managing workload, but I'll agree that in some cases it might help.
 
But ideally there should be a way to unlink MIDI and audio buttons for the purpose of making playback during mute/solo operations seamless. Ideally a per-track setting would be welcome. They can default to linked, then one can unlink them if necessary. And maybe even a global setting that says new tracks should default to either linked or unlinked.

SilkTone
But ideally there should be a way to unlink MIDI and audio buttons for the purpose of making playback during mute/solo operations seamless. Ideally a per-track setting would be welcome. They can default to linked, then one can unlink them if necessary. And maybe even a global setting that says new tracks should default to either linked or unlinked.

I understand totally, but this begs the question of how many preferences and options are going to be built into a program, and how complex the setup for tracks should be. Offering multiple options for a very fundamental feature works against the odds of it being implemented. Prioritizing is also an issue. I'm sure thousands of people have preferences they would like to see, but would others want those same preferences? There was another thread asking for more streamlined preferences.
 
At some point, I think it's necessary to decide what qualifies as best practices, implement that, and if an existing toolset allows for workarounds for minority situations, that's sufficient. Creating additional layers and options runs the risk of making the program more daunting and ultimately, more difficult to use. For example, it appears you didn't know about Quick Grouping, which was an immensely powerful option introduced in prior versions of Sonar. My "tip of the day" thread garnered a lot of "I didn't know that" responses. Sonar is already an extremely deep program. I'm definitely not saying Sonar should do a Final Cut X and be dumbed down, but ideally every addition - and also, every legacy decision - needs to be evaluated under the lens of "will this make for a better translation of musical inspiration into physical reality?" 
 
As Noel pointed out, this design decision was made 12 years ago. Back then, the best practice probably was to conserve CPU resources wherever possible, with the tradeoff being a less seamless MIDI experience under some circumstances. However, with multicore computers and faster processors, it may very well be that the best practices have changed, and that the average Sonar user's computer has no problem with "all MIDI all the time." If so, then just make that the default and if some people have issues with older computers, the tracks can be frozen or rendered. IMHO I don't think there would be any need for a preference; just unlink them and say "we have fast enough computers now for the majority of users" and be done with it.
 
Of course, there's also the question of feasibility and importance to the user base in terms of prioritizing. Personally, i have a screaming 12-core machine and can cope with "all MIDI all the time" so this would be not only be okay with me, but like you, I would probably find it preferable. However, it's also important to be sensitive to users with less powerful machines.
 
Cakewalk is now aware of this issue, and there is a dialog going on...so we'll see what shakes out. Meanwhile, there are some pretty painless workarounds. 
 
 

CakeAlexS
Makes sense though to design a product as lean and as CPU efficient as possible by default then open up via preferences if needed.

No matter what the preference is, to mute a track's audio you're going to have to click on something - so just mute the instrument's MIDI track instead of its audio track. The only downside is it's an extra click if the track isn't already selected. But that also gives the option of doing it on a per-track basis. 
 
But...it would be really cool to have adaptive programs! So Sonar would analyze your system specs, decide what you could get away with, and set up preferences accordingly. If you started going nuts with virtual instruments and the CPU started going crazy, a dialog would pop up that said:
 
You're running out of CPU power. Would you like to:
 
Increase latency to the next highest default
Freeze all virtual instrument tracks you haven't edited in the last 30 minutes
Freeze all virtual instrument tracks you haven't edited in the current session
 
That would be interesting...

Besides the reasons stated above I don't have any strong objections to disabling the auto muting and soloing from the synth audio track. The feature pre-dates quick grouping and was a handy way to quickly mute/solo all related synth MIDI tracks without needing to hunt them down. It was what people wanted at the time.
The code for synth mute and solo is centralized fortunately so changing it is not difficult, however I need to discuss this internally and also make sure that there are no side effects to changing this behavior in case something else relies on this functionality.

As an option cool.. Thanks.

Noel, excellent! Thanks.

I'm sorry but I have to retract one part of that fix. I can't remove rules 1 and 2 for the solo case. There was a good reason for those.
 
The reason is this:
If you solo just the synth audio track without soloing the synth MIDI track you will hear silence. That would be confusing and unacceptable behavior. The synth audio and MIDI tracks need to be soloed together, so I need to retain the rules 1 & 2 for solo.
 
Hopefully I don't find anything that prevents the mute case :(

The way I read it, if the synth's audio and MIDI tracks are completely unlinked, then soloing the audio track will not solo its MIDI tracks so there's nothing feeding that audio track because only it is solo'd.  However, if you mute the audio track then it doesn't matter if anything is or is not feeding that audio track - it's muted.   At least I think I have that right... 
 
BTW, great discussion, very interesting.