How can I temporarily disable a particular patcher window

Apr 24, 2012 at 6:20pm

How can I temporarily disable a particular patcher window

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.

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

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.

Is this possible?

Thanks,
D

#63196
Apr 26, 2012 at 10:40am

Anyone know or am I out of luck on this?

#227973
Apr 26, 2012 at 12:14pm

{select} message to [thispatcher] ?

#227974
Apr 26, 2012 at 12:17pm

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

#227975
Apr 26, 2012 at 12:32pm

sorry, ‘select’ MESSAGE

– Pasted Max Patch, click to expand. –
#227976
Apr 26, 2012 at 12:34pm

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.

#227977
Apr 26, 2012 at 2:12pm

Hello,

Have you tried to unselect “All Windows Active” maxMSP (menu) options ?

I did an external [quebec] that reports edit status of the attached patcher ; perhaps it can help you …

#227978
Apr 26, 2012 at 3:21pm

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.

#227979
Apr 26, 2012 at 3:35pm

Hello,

“patcher be temporarily disabled while I’m editing …”

with custom external …

Attachments:
  1. jojo.zip
#227980
Apr 26, 2012 at 3:38pm

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.

#227981
Apr 26, 2012 at 3:47pm

Hello,

[quebec] is just a custom external that i use to get patcher’s attributes i can not get with maxMSP native objects ; in this case it just reports the “edited” status ; it does NOT stop anything ;-)

#227982
Jan 1, 2014 at 8:58am

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!

#277107
Jan 1, 2014 at 10:55am

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

#277112
Jan 1, 2014 at 2:19pm

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.

#277117
Jan 1, 2014 at 2:21pm

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

#277118
Jan 1, 2014 at 3:22pm

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.

#277120
Jan 1, 2014 at 4:22pm

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.

#277121
Jan 1, 2014 at 4:22pm

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!

#277122

You must be logged in to reply to this topic.