How to achieve the same thing as 'stopwindow'?
dac~ accepts the message 'startwindow' (start audio for just that patcher) but not 'stopwindow' (stop the audio for just that patcher). Is there a way to do this?
(I think stopwindow may have existed in years gone by...?)
(There is a similar, rather old question here https://cycling74.com/forums/how-can-i-temporarily-disable-a-particular-patcher-window but, I am not asking about a bpatcher, I just want to turn off all audio in a regular patcher window, but leave the others on. Re the 'active' object suggestion in the other thread, that just reports the on/off status, but it can't set it.)
Check patcher inspector
Ah, thanks Source Audio, that's exactly it (and rather obvious when you point it out!)
Appreciated!
i turn audio off (globally), then enable those windows again which i want to continue (it could be only one or all but one) using "startwindow".
it ended up as abstraction called 110.windac~, which otherwise works like dac~.
in opposite to these freaky patcher arguments it can all happen programmatically, so that this behaviour could also be turned off again if you want... or let you save presets for sets of running/stopped patcher windows.
outside of a live situation this is totally acceptable.
I can't get the isolateaudio-option to work. When I stop the dac (with a stop-message) in a subpatcher, the audio gets turned off in all other patchers as well. Aiming for the bypass function of the Max4Live-devices...
subpatchers are not part of this isolation, only main patchers.
But you can turn dsp using mute, disable etc messages to subpatchers and bpatchers
Ah yes, but it doesn't work when I put the mute object in a separate bpatcher to make it neat. Maybe I just can't have it all?
unlike [*~ ], all [dac~] objects in the same runtime are only aliases of the same dac~, even if the adress different outputs.
as soon you have accepted this idea, a solution is obvious.
Great, thanks Wil!