@brad
Hi and thanks for the new Solo function.
I’d like to add my experience to the above.
Currently have two racks and an instrument instantiated.
Solo rack 1 and rack 2 doesn’t mute.
Solo rack 2 and everything else mutes.
Solo the instrument and rack 2 doesn’t solo.
Something not quite right.
Hrm… something’s obviously not right here, but similar tests here seem to work fine. Can you send me a simple song/rack set that demos the problem?
Hi all,
I am running win 7 x64 and the solo function works as explained. Nice feature, thanks to all of you and Brad for making this happen!
Dave
@brad
Hi - I think you own Omnisphere and synth1 is a freebie which is here if you would like to grab it:
http://www.geocities.jp/daichi1969/softsynth/
Solo the Omnisphere rack.
The ‘Bunch of Synth1’ rack contains 2 instances of Synth1.
There is a split point which is from C2 - D3 so make sure you play in that range when you put the Omnisphere rack into solo.
On my system, the synth1 bottom end continues to play - and I have now recreated this, using existing racks into a new song, just to make sure it wasn’t an anomaly.
Actually - I’ve just found the issue. It could be operator error, but I’ll let you be the judge. 
What is happening is that the contents of the Bunch Of Synth 1 rack are directly routed to the main speakers and not to the rack output. If I swap the outputs to rack out then it works. The question is, should those be shut down too? I’ll leave it in the compromised state for you to consider.
brad solo test.cantabileSong (30.3 KB)
Ah ok… that makes sense.
This is either “by design”, or a “design oversight”
The Solo function works by muting the output routes of objects in the song/rack where the object lives. For plugins and media players this works fine. For racks it works if their output is routed back to the parent song, but not so well if they’re sending to the environment ports or the ports of another rack directly.
Let me think about this a little. Worried it might get really messy/confusing if the parent song starts trying to break into a rack to fiddle with its output routes.
@Mistheria - does this explain the behaviour you’re seeing? ie: are your racks routed directly to environment output ports?
Update: I thought about it, did some experiments and have made a change so when a rack is muted by the parent song any of it’s internal routes to output ports (including environments ports and other racks) are also muted, as shown in following screen shot (the route from PianoTeq to Main Speakers is shut off by the rack being muted in the parent song).
Still need to test it a bit, but I’ll probably include this in the next build.
Brad
Available now in 3219…
That nailed it!
There are some ambiguous situations which can occur but I don’t think it serves any purpose to get overly pedantic and turn a simple solution into a nightmare.
But - just for the helluvit… 
On the supplied project,
Hi Ade,
What you’ve described there sounds like it’s working as designed. Remember that the solo operation is a per song/rack setting - not global. So if you’re soloing a plugin in a rack, it doesn’t affect the solo/mute state of things in the parent song. Similarly, if a rack is muted by a parent song solo then the plugins inside the rack won’t show the mute crosses, because they’re not muted - only the routes to output ports are muted.
I deliberately decided to leave the meters running for solo muted objects to reflect that this is only muting the output routes - not shutting down the plugin.
Also, control key on the Solo button in the rack header has no effect - perhaps it should, I’ll put that in.
Brad
Thanks @brad ,
I understand completely. The approach you’ve taken achieves a result which is beneficial to the end users but steers clear of the minefields.
Yes to adding the control key to the rack header - along with a Solo button, which currently doesn’t appear in a rack unless an outside object has been put in solo first. From that point on, a solo button will appear in that rack.
Overall it seems to be achieving what you set out to do, despite my best efforts to break it. 
Thanks @Ade,
I’ve put in a fix for the Control key which will be in the next build. I couldn’t reproduce any problem with the solo button not appearing in the rack header - it should appear at the same times it appears in the parent rack - ie: when Solo Control is enabled on the rack in the parent song.
Brad
Hi Brad
Please try opening a clean song before any solo is invoked anywhere.
Install a rack and open it.
Do you see a Solo button in the rack header?
Please try this with the rack window not split.
Hi Adrian,
I tried this on 3219 and it shows a solo icon in the header when expanded with a new song, new rack but on old songs it doesn’t show them (icons in header of rack) when I first open the rack. But if I press the solo button before I open the rack, then the icon appears in the header and remains there (while activated) until I change songs. If I deactivate from the header, close the rack and re-open the rack no icon again. It does not remember this when I save and comes back when reloaded acting the original way (no solo icon initially in header when expanded except when activated before opening rack). Just thought it would add to discussion.
regards
Dave
Once solo is invoked at the top level and the rack opened, the icon will appear.
Ah got it… will fix. (thanks!)
Fixed in 3220 (available now)
Working with v. 3220, the SOLO function definitely works now! Great!
