stevec
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.

First of all Noel, you remain totally awesome   And not just for putting up with me. This thread gives some fascinating insights into the software design process.
 
I see what Noel is saying, Solo mutes everything else and you can't have the instrument's MIDI data muted or you won't hear any audio. But I've been thinking about this some more. Seems to me a MIDI track will be doing one of three things:
 
1. Controlling a VI.
2. Sending data through the physical output to control external hardware.
3. Sending control signals to a processor that accepts MIDI. 
 
In any of those cases, it makes sense that the targets for the MIDI data should always be updated with the latest MIDI information, regardless of the mute or solo status of any track. 
 
The only place where I see an issue is this. Suppose you have a folder for a multitimbral synth with one audio track (representing the sum of the multi-timbral instruments) and multiple MIDI tracks feeding that synth. If you solo the MIDI track, you would want to mute to the other MIDI tracks so you hear only the one instrument. (Of course this would not be an issue if the synth had multiple audio outputs, because you could just solo the desired audio output.) I think the following rules would accommodate all situations:
 
1. If any MIDI track is muted, only that track is muted. All other MIDI tracks remain unmuted unless muted manually.
2. If a synth's MIDI track is soloed, all other MIDI tracks assigned to that synth are muted.
3. If a synth's audio track is soloed, any unsoloed audio tracks are muted but this has no effect on any MIDI tracks.
4. If a synth's audio track is muted, only that track is muted and this has no effect on any MIDI tracks.
 
Am I missing anything?
 
Basically, this protocol treats VIs as essentially audio tracks. The more I think about "all MIDI all the time," the more it makes sense to me because I won't have situations such as (for example) a synth mutes in the middle of a pitch bend, then unmutes later in the song but missed the pitch bend data that returned it to normal pitch. 
 
 

stevec
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... 

 
Steve, you have to see a solo as simply muting all other non-soloed tracks. So internally there is no "solo" mode for a track per se, it is just that the control logic simply decided to mute it internally due to another track being soloed.
 
So... In order to have a completely unlinked MIDI and synth audio track work properly together during a solo, all you have to do is... not mute the MIDI track.
 
Anderton,
 
The four points you list sounds like it should work properly.
 
Now of course if one really wants to use a mute button as a way to save CPU cycles, nothing stops you from muting the MIDI track itself.
 
I'm wondering if treating MIDI and audio mute/solo states as complete different entities makes sense. So if one mutes or solos an audio track, only outputs of audio tracks are muted or unmuted, and no MIDI tracks are touched. On the other hand if one mutes or solos a MIDI track, only MIDI tracks are muted or unmuted, and no audio tracks are touched.

Noel Borthwick [Cakewalk]
Hi guys,
This gets hard to convey in a few sentences

Actually I think you conveyed it really well, and your choice of how to implement makes sense. I do think it will represent an improvement for those using virtual instruments.
 
As you know, I am unburdened by any knowledge whatsoever of how coding works . I appreciate your looking at this to determine what is and is not doable.
 
All hail THE NOEL!

 
Noel,
 
How about this: An option to either leave the behavior as it currently is (the default), or simply unlink all MIDI and audio track mute and solo buttons? This will basically disable your #1 and #2 cases for both mute and solo if the option is checked:

[ ] Unlink MIDI and synth audio mute and solo buttons

 
The advantage is that you can't break any existing use cases, and at the same time this will get the feature some good field testing to make sure it doesn't result in some undesired behavior (in which case one can simply switch the option off again).
 
This one can make a nice difference in how smooth Sonar feels while muting/soloing.

I think were going in circles a bit. Soloing a synth MIDI track is implicitly leaving the synth audio tracks unmuted by soloing them as well. SONAR is a sequencer that supports both hardware and software MIDI and solo and in general mute work consistently across both hardware and software tracks. There is a tremendous amount of complexity dealing with mutes and solos that I can't get really detail here. Its not as simple as having an option to do it one way or another.
 
>>Noel I don't understand. If MIDI tracks never get muted when audio tracks get soloed (either directly or due to >>another track being soloed), why would we need to care about which MIDI track contributes to any given output?
MIDI tracks DO get implicitly muted when something is soloed in SONAR causing them to stop sending MIDI. That's a pretty fundamental paradigm that every version of the sequencer has had and would be pretty risky to mess with. 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. 
 
As explained earlier the best that can be done at this point is no longer muting synth MIDI tracks when the parent audio track is muted which should alleviate the main issue you raised. Even that was a pretty complex change to make.

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 

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.

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.

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.

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.

Craig, agreed. The changes Noel did is already a nice step forward. Thanks Noel. Maybe it can open the door for continued improvements on this front.
 
Craig, I also think that if there was a way to A/B the two different implementations, many people will want this change and will weigh in their opinions more in a thread like this. The closest we can get is by freezing all soft synths to get a feel for what glitch-free muting and soloing would be like.

stevec 
Speaking of which... isn't this the wrong forum?      <ducks>     

It would be if it was started today, but it's winding down and people know where to look for it. It will fall off the front page before too long anyway.
 

Anderton

stevec 
Speaking of which... isn't this the wrong forum?      <ducks>     

It would be if it was started today, but it's winding down and people know where to look for it. It will fall off the front page before too long anyway.
 

+1

Well now that you guys bumped the thread again...
 
I read Noel's last post again and realized he meant that using unlinked MIDI and audio track mute/solo logic itself is the "corner case". I'm not sure I agree that it is a corner case, as muting and soloing during a mixing session is very central to the workflow. Maybe it makes more sense to say it is a different implementation of this feature, not a corner case?
 

konradh
The linked solo buttons are helpful to me.
• I put all the MIDI in a separate folder so my mixing desk is cleaner and only has audio tracks.

 
If one were to unlink MIDI/audio track solo logic, then this would be an interesting problem to solve since what is the folder's MSR buttons supposed to control then? Maybe for folder MSR buttons only, treat those nested MIDI and audio tracks as linked like it works today?
 

• If I want to Solo an instrument, it is convenient that Sonar solos the MIDI track(s), too.

 
In this case by not muting any MIDI tracks (internally), you will get the correct result.
 

In the case of RealGuitar, I always have two MIDI tracks (one for notes and one for patterns) in addition to the audio track.

 
I do almost the same thing with RG, but instead of the second MIDI track with chord clips, I use a VST plugin where I enter my chords and then feed that into the second RG MIDI track. This is actually a good example of where not muting the MIDI tracks internally will result in smoother mute/solo operations since RG stops playing the whole chord if its MIDI data is interrupted. Noel's mute change will come in very handy here for sure.
 

Also, if I hit Solo on the drum folder, Sonar conveniently solos the drum MIDI that is in the MIDI folder.

 
This would be the same problem as in your 1st point you mention.

Agreed! I'd also like a method to mute/unmute a track/channel with a simple midi message. How hard can that be? I cannot find a way to accomplish this SIMPLE TASK.