dhjdhjdhj

I've developed a live environment where I have a collection of devices such as external mixer, control surfaces, VST editors and so forth. In the middle is a bpatcher into which I load a patcher that defines behavior required for a particular song or performance. That patcher essentially connects all the various pieces together, allows both audio and MIDI routing/transformations, and so forth.

That patcher can be replaced on the fly for a different song.

Now, by clicking on the "front" message at the bottom left of the patcher, the original patcher is opened and so I can edit it to change behavior. However, when I do that, the objects in the embedded patcher continue to work.

I'm hoping that there is a way to have that embedded patcher be temporarily disabled while I'm editing.

See picture:   http://i.imgur.com/PpKCH.jpg

how-can-i-temporarily-disable-a-particular-patcher-window

Anyone know or am I out of luck on this?


I am afraid I don't understand this. What is {select}?

I am afraid I don't understand this. What is   {select}?


I don't understand the suggestion. It's not a question of selecting a patcher. The issue is how to temporarily completely disable a patcher so that even though it's open, it doesn't respond to any messages or incoming events.

As I understand it, if All Windows Active is disabled, then the only patcher that runs is the one that has the focus. That is NOT what I want.

I want all windows to be active EXCEPT for a designated patcher (actually a patcher embedded in a bpatcher inside another patcher)

Worst case, I could actually REMOVE the embedded patcher temporarily but I'd really rather be able to just turn it off.

What exactly does "quebec" do? How does it stop some patcher from running temporarily?

Note that I don't want the patcher I'm editing to be disabled. I want the instance of the original patcher that's embedded in a bpatcher to be disabled.

I am facing the exact same issue, DHJDHJDHJ. I am also creating a live electronic performance set and I need to be able to seamlessly switch programs with every song. Some patches are highly complicated and use a whole lot of cpu, so for that reason I want to temporarily completely disable subpatches so they do not use any cpu.

I hope you have found a solution for this in the meantime. I'd like to hear from you!

I am facing the exact same issue, DHJDHJDHJ. I am also creating a live electronic performance set and I need to be able to seamlessly switch programs with every song. Some patches are highly complicated and use a whole lot of cpu, so for that reason I want to temporarily completely disable subpatches so they do not use any cpu.
I hope you have found a solution for this in the meantime. I'd like to hear from you!


The most direct way is with the 'enable' message to the pcontrol object ('enable 0' to disable, 'enable 1' to re-enable). That works and will likely continue to work, but it is officially discouraged in favor of the 'mute' message to poly~ (which requires that you convert the patches you want to mute into poly~-compatible subpatches, but that's now the preferred way to disable audio in a subpatch).

What exactly does that disable? I vaguely remember trying that a long time ago --- I think it disabled the MIDIIN object which was of no help to me since MIDIIN was being handled in its own patcher which then used SEND/RECEIVE to distribute MIDI events.

To me, disabling a patcher window means that no events should be processed in that window, regardless of whether they're traditional messages or DSP.

@jorickbronius I never really solved this problem to my satisfaction --- the poly~ mechanism would have required me to make major design changes to my system and somehow I just never found the time to do that. A mechanism that just causes a patcher window to be completely turned off would be far more helpful to me.

You wrote, "To me, disabling a patcher window means that no events should be processed in that window, regardless of whether they’re traditional messages or DSP." You seem to be looking for that capability in a single object or message, which doesn't exist as such, so you probably need to assess how to design your program in a way that allows you to disable the things you want to disable efficiently and effectively using the means provided by Max. There are many ways provided in Max to allow you to disable whatever you want to turn off. In this instance, your concept of what "disabling" a window means is different from that of Max's pcontrol object. The 'enable 0' message to pcontrol disables MIDI and audio in a subpatch. (That stops MSP processing in that patch, which saves the CPU resources referred to by jorickbronius.) You can also use the 'close' message to pcontrol to close a patch if you want to make its UI objects inaccessible. (It's rather confusing to allow your user to see UI objects that do nothing anyway.) Or hide the objects. Or fade them out and set their 'ignoreclick' attribute to disable them. Want to stop the flow of messages to a patch? Stop the processes that are sending it messages. Want to stop the flow of messages within a patch? Use gate. Want metros to stop sending bangs? Turn them off. You get the idea.

Sigh --- I WANTED the ability to turn off event processing for all objects inside a patcher (patcher seemed to be a useful zone of control).

That "enable 0" may very well turn off the midiin object in a patcher, but if you are receiving MIDI events in a patcher via the [receive] object, that does NOT get turned off.

As for your other suggestions (gates, etc), I've long since configured my system to work that way (actually using named global identifiers so I can selectively turn on/off various subsections, but it would have been much more convenient to be able to just tell a specific patcher to stop processing.

In my designs I don't only want the MSP processing to stop, I also need the whole logic thing to stop in it's entirety. Which is not possible with the 'close' or 'enable 0' messages if my testing earlier was accurate.

But I think I figured out a way that could be rather functional to me to entirely stop a subpatcher actions. I haven't yet figured out all the cons & pro's but I have a set up that basically allows me to send script commands to a 'thispatcher' object so that it can load a bpatcher with a scriptingname, when the bpatcher is loaded and the scripting name set (using @varname) I can automatically make it connect to a 'dispose' (be careful with that!) message to the thispatcher object inside the loaded bpatcher to make it vanish entirely. So when I have several seperate subpatcher files I can load them and unload them on command. It's quite a rigorous approach, especially when working with subpatchers using multiple in- and outlets, but I think it could work nicely!

I'll keep you posted. Btw: Thanks for your replies, they are very helpful in finding another way to fix this!

7 years on identical question. Is there best practice by now?

To be specific: I would like to disable the entire bpatcher. completely.

7 years on identical question. Is there  best practice by now?

To be specific: I would like to disable the entire bpatcher. completely.
and then enable it again later.


I gave up on this several years ago and we ended up developed a new audio plugin host for live performance. I drive it from Max (over OSC) so as to get the benefit of Max MIDI manipulation but I no longer depend on any audio processing in Max/MSP and so I'm able to use a simple gate in front of the input to the bpatcher to enable/disable it.

7 years on identical question. Is there  best practice by now?

i think active wont work in bpatcher because bpatcher isnt a patcher window.

Old thread but, for completeness... I was asking this same thing, and 

(It works with bpatchers, but you need to set the option in the patcher that contains the instance of bpatcher, not the bpatcher itself.)

Old thread but, for completeness... I was asking this same thing, and received exactly the answer here

How can I temporarily disable a particular patcher window