Noel, sorry I don't want to make this discussion go around in circles, and I appreciate your time. But something just doesn't make sense to me. You don't have to answer my question, maybe someone else can that knows the answer...
 

When you solo a synth audio track there is no way for the program to determine which MIDI track contributes to that specific output, so it has to specifically solo all related MIDI tracks or you could get silence. 

 
That is the part that doesn't make sense to me. In my proposed scenario, how can you possibly get silence on any soloed synth track if none of the MIDI tracks stop feeding into their respective synths?
 
Let's imagine for a second we leave all MIDI tracks unmuted at all times when we solo any audio track (meaning all MIDI tracks still feed data into all of their respective synths). So if a particular MIDI track is feeding into that soloed synth track, then we would hear it. In fact any MIDI track feeding into that soloed synth track will be heard. So that solves the problem of "there is no way to know which MIDI track contributes to that specific output".
 
On the other hand, any MIDI track that feeds into any other non-soloed synth track will be indirectly muted because its own synth track is now muted. So this is producing the exact expected results, and no special logic need to be applied to MIDI track's mute/solo states.
 
Here is an experiment: Freeze all MIDI/synth tracks and play around with mute/solo buttons. You will always get the expected results (and much more seamless too). This is essentially the same behavior one would get if MIDI tracks always feed into their synth tracks (unless you explicitly mute the actual MIDI track).

As a sidebar...I do know that Solo/Mute options exist at pretty fundamental levels. It always bothered me that Ableton Live can't record solo button presses when you record a live performance, which is a big deal to me because of how I do breakbeats. Ableton replied Solo was intended as a diagnostic tool in the studio, not a live performance option. It seemed it would be simple enough to include a preference that recording would take the Solo button into account, but they said the functionality was so deep in the code basics that changing it would be next to impossible...and that I wasn't the only person who had asked for this. They told me they had a file with my name on it that was filled with nothing but comments about whether this was feasible or not 

SilkTone

When you solo a synth audio track there is no way for the program to determine which MIDI track contributes to that specific output, so it has to specifically solo all related MIDI tracks or you could get silence. 

 
That is the part that doesn't make sense to me. In my proposed scenario, how can you possibly get silence on any soloed synth track if none of the MIDI tracks stop feeding into their respective synths?
 
Let's imagine for a second we leave all MIDI tracks unmuted at all times when we solo any audio track (meaning all MIDI tracks still feed data into all of their respective synths). So if a particular MIDI track is feeding into that soloed synth track, then we would hear it. In fact any MIDI track feeding into that soloed synth track will be heard. So that solves the problem of "there is no way to know which MIDI track contributes to that specific output".
 
On the other hand, any MIDI track that feeds into any other non-soloed synth track will be indirectly muted because its own synth track is now muted. So this is producing the exact expected results, and no special logic need to be applied to MIDI track's mute/solo states.
 
Here is an experiment: Freeze all MIDI/synth tracks and play around with mute/solo buttons. You will always get the expected results (and much more seamless too). This is essentially the same behavior one would get if MIDI tracks always feed into their synth tracks (unless you explicitly mute the actual MIDI track).

I already explored that scenario - here is how it breaks. As I explained solo in SONAR and I expect most sequencers is handled as a special kind of mute state "mute due to solo". When you solo any track (bus solo is a whole different animal which I wont get into) all other non soloed midi tracks automatically get a mute due to solo state. In response to this they do not render their data (the equivalent of streaming silence for audio).
 
Imagine for example that mute due to solo was ignored and the MIDI track data was indeed sent to synths. Consider a drum instrument with 8 audio outs and 16 MIDI tracks sourcing that synth like this:
 
Audio Track 1-8
MIDI track 1-16
 
If you solo audio track 1 all MIDI for tracks 1-16 will continue to be sent. So far so good - you will continue to hear audio track 1.
Now additionally solo MIDI track 1. The user expects to hear only output corresponding to track 1 at this point. However since all other tracks continue to send data to the synth there is no guarantee of this because if MIDI track 2 is output from Audio track 1 you will continue to hear it! That is obviously unexpected behavior.
With the current implementation MIDI tracks other than track 1 will automatically be muted due to solo and will not sound which is the expected behavior.
 
The bottom line is as Craig said, Solo is primarily a mixing tool rather than a realtime performance tool. For the behavior you want you should route your desired synth outs to buses and solo or mute those if you need realtime performance control..
 

Noel Borthwick [Cakewalk]
I already explored that scenario - here is how it breaks. As I explained solo in SONAR and I expect most sequencers is handled as a special kind of mute state "mute due to solo".

 
Noel, I understand this. There is a visible mute state (the actual visible button state) and the internal mute state. The internal mute state is derived from not just the visible mute button state, but also logic based on other track's solo states etc. When one soloes a synth audio track, one can say it's corresponding MIDI track is also soloed. However it is equally accurate to say it's MIDI track isn't soloed, it just isn't muted internally. Simple semantics but it seems to throw people off of the point I'm trying to make. Since "mute" can have these two different meanings, I think it is better to say "muted" and "silent" to describe the two different ways to make it not produce output.
 

Imagine for example that mute due to solo was ignored and the MIDI track data was indeed sent to synths. Consider a drum instrument with 8 audio outs and 16 MIDI tracks sourcing that synth like this:
 
Audio Track 1-8
MIDI track 1-16
 
If you solo audio track 1 all MIDI for tracks 1-16 will continue to be sent. So far so good - you will continue to hear audio track 1.

 
Correct, makes sense.
 

Now additionally solo MIDI track 1.

 
Noel this is not what I was saying. I was specifically talking about muting/soloing synth audio tracks only. In that scenario one never needs to make any MIDI tracks "silent". I think you will agree that not making any MIDI tracks silent won't break anything, and will result in the correct behavior, correct?
 
However the scenario you describe with soloing the MIDI track is a different use case. In that case, yes of course one needs to follow solo/mute/silent logic just as it is now. I never said this should change.
 
This is a better description of what I mean:

1. Audio tracks follow standard mute/solo/silent logic just like it is today, however it is only based on the state of other audio tracks.
2. MIDI tracks follow standard mute/solo/silent logic just like it is today, however it is only based on the state of other MIDI tracks.

You will find that if the above logic is followed, it doesn't break any use case. Certainly not the one you described above.
 

The bottom line is as Craig said, Solo is primarily a mixing tool rather than a realtime performance tool. For the behavior you want you should route your desired synth outs to buses and solo or mute those if you need realtime performance control..

 
Noel I was not talking about a live performance use case at all, Craig brought that use case up. It is specifically in the mixing stage that the current behavior is distracting and unnecessary.
 
I hope you see this as a constructive discussion on how to make SONAR even better than it is. I'm certainly not trying to come across as difficult or confrontational or anything, just a good-old fashioned geeking out discussion about something we all love
 
BTW, you are the only one that can actually test out these theories. There is no way for any of us to unlink the MIDI and audio mute/solo logic and see if it breaks anything. Dollars to doughnuts if you try my suggested separation of logic above, you won't be able to find a broken use case. The only one could be for external synths not feeding back into SONAR, however maybe in that case there could be a way to explicitly link just that MIDI track.

SilkTone
Noel this is not what I was saying. I was specifically talking about muting/soloing synth audio tracks only. In that scenario one never needs to make any MIDI tracks "silent". I think you will agree that not making any MIDI tracks silent won't break anything, and will result in the correct behavior, correct?
 
However the scenario you describe with soloing the MIDI track is a different use case. In that case, yes of course one needs to follow solo/mute/silent logic just as it is now. I never said this should change.
 
This is a better description of what I mean:

1. Audio tracks follow standard mute/solo/silent logic just like it is today, however it is only based on the state of other audio tracks.
2. MIDI tracks follow standard mute/solo/silent logic just like it is today, however it is only based on the state of other MIDI tracks.

You will find that if the above logic is followed, it doesn't break any use case. Certainly not the one you described above.
 

 
Yes I understand, yours is yet another corner case. What you are describing works on paper but in practice it wouldn't be worth the effort and complexity it would take to implement for this narrow case. In SONAR mutes and solos are agnostic of track type in general, or synth audio tracks for that matter so it would be pretty hard to tie it into those special cases. Also the moment a MIDI track is soloed all that logic would have to be thrown away. Honestly we couldnt justify the cost to implement and test this for such a narrow case and it would over complicate the code considerably. I would be very surprised if other DAW's did this either - if so its probably coincidental based on their design architecture.
 
>>I hope you see this as a constructive discussion on how to make SONAR even better than it is
Yes no worries. I appreciate your suggestions and indeed handling the mute case was relatively simple. Hopefully something else doesn't break as a result of it :) The code for this stuff is very complex.
 

Noel Borthwick [Cakewalk]
What you are describing works on paper but in practice it wouldn't be worth the effort and complexity it would take to implement.

 
That's what Ableton said about recording the solo button...
 

Yes no worries. I appreciate your suggestions and indeed handling the mute case was relatively simple. Hopefully something else doesn't break as a result of it :)

 
If only one of the proposed functions could be handled, that's certainly the one I would have chosen.
 
Thanks for your participation in this, Noel, I know how valuable your time is. I guess you can return to work on the Hovercraft's anti-gravity bug now.

Hm.

A question.

If MIDI tracks always send MIDI when a single audio track is soloed what would happen to those of use who use real, actual hardware synths?

My projects usually have a bunch of MIDI tracks feeding external hardware which are returned to audio tracks and monitored via input echo. There will also be audio tracks taking input from e.g. guitar, bass, whatever.

If MIDI is always sent, then if the MIDI hardware is being monitored via a mixer or the interface's "direct through" capabilities then mutes would also have to be applied at the mixer or interface as well otherwise the synths would not be affected by audio track soloing at all.

Unless Sonar could tell the difference between a VSTi's MIDI input channel and audio output and other MIDI tracks and only leave active the VSTi ones perhaps....

My honest opinion at the moment is that solo and mute aren't broken and don't need fixing.

tlw
Hm.

If MIDI is always sent, then if the MIDI hardware is being monitored via a mixer or the interface's "direct through" capabilities then mutes would also have to be applied at the mixer or interface as well otherwise the synths would not be affected by audio track soloing at all.

Yup that sounds about right and seems normal. Mute the MIDI clips otherwise or root to another mixing tool.

tlw
My honest opinion at the moment is that solo and mute aren't broken and don't need fixing.

They're not broken, but I think it's cool that Noel has allowed muting a synth's audio track without muting its MIDI track. This means if you mute a synth track's audio and unmute it later, the instrument will have followed and acted on pitch bend, controller data, note offs, etc.
 
I do think this is an improvement that takes into account today's computers, where saving every last bit of CPU power isn't as essential as it once was...and if you do need to save it, you can always render or freeze.
 
So as it is currently, I think you're okay with using external synths and having them behave the way you want. Silk Tone gets most of what he wants, and when I mute a VI during mixing, it will be playing what it's supposed to be playing when it comes back in. It all sounds good to me.

Noel Borthwick [Cakewalk]
Yes I understand, yours is yet another corner case. What you are describing works on paper but in practice it wouldn't be worth the effort and complexity it would take to implement for this narrow case. In SONAR mutes and solos are agnostic of track type in general, or synth audio tracks for that matter so it would be pretty hard to tie it into those special cases. Also the moment a MIDI track is soloed all that logic would have to be thrown away. Honestly we couldnt justify the cost to implement and test this for such a narrow case and it would over complicate the code considerably. I would be very surprised if other DAW's did this either - if so its probably coincidental based on their design architecture.

Noel I assume when you say "corner case" you are referring to my last sentence that mentions a MIDI track feeding an external synth. I only mentioned it because it is the only case I can think of where unlinked MIDI and audio track mute/solo logic could result in undesirable behavior. What I meant was that for that case, maybe there can be a right-click option on the MIDI track to link it back to audio track mute/solo logic. Not that SONAR should somehow figure out which MIDI tracks to link automatically.
 

tlw
Hm.

A question.

If MIDI tracks always send MIDI when a single audio track is soloed what would happen to those of use who use real, actual hardware synths?

My projects usually have a bunch of MIDI tracks feeding external hardware which are returned to audio tracks and monitored via input echo. There will also be audio tracks taking input from e.g. guitar, bass, whatever.

If MIDI is always sent, then if the MIDI hardware is being monitored via a mixer or the interface's "direct through" capabilities then mutes would also have to be applied at the mixer or interface as well otherwise the synths would not be affected by audio track soloing at all.

Unless Sonar could tell the difference between a VSTi's MIDI input channel and audio output and other MIDI tracks and only leave active the VSTi ones perhaps....

 
This is exactly the corner case that Noel (I think) and I are talking about. What I'm suggesting is that there can be a per MIDI track option that will link its mute/solo logic back to the audio track mute/solo logic. Then it would work like it does today.
 

My honest opinion at the moment is that solo and mute aren't broken and don't need fixing.

We are so used to the way it works now that most of us think this is a good as it gets. Follow my suggestion of freezing every soft synth in a complex project and then play around with the mute/solo buttons. Now you know how good it can be.