Forums > MaxMSP

bpatcher and thispatcher (feature request?)

May 20, 2011 | 12:51 pm

Is there any way to talk to a parent patch from a [thispatcher] contained in a [bpatcher]?

I noticed that in the helpfile for the [thispatcher] it states: "See the bpatcher help file for the use of the thispatcher object with bpatchers", but I cannot find what this sentence is referring to :( I was hoping for a bit more insight and some unknown tricks…

If this is not possible, then this would be a highly desired feature request. You could implement something like, first of all, an object very similar like [thispatcher], called [parentpatcher], which would also do an internal automatic check, if the current patch is a subpatch in the first place. I know this is possible in javascript, *but* the problem is that not everything that you can do with a thispatcher can be done in javascript, like setting the dirty bit. Oddly enough, checking the state of the dirty bit is, in turn, only possible in javascript and not through the [thispatcher]. Inconsistencies like these (not supplying a getter for each setter function and vice versa) annoy me about Max a bit, to be honest.

Also, I could think of something like sending a message such as "script send parent dirty" to a [thispatcher] sending whatever you would have sent to a normal [thispatcher] in the parent, which is only virtual though, as in, the user does not need to create an actual [thispatcher] in the parent patch. Although, I find the first idea more elegant.

Also, thispatcher should be able to report changes made to the attributes of the patch. This could be done automatic or manual polling perhaps. Again, thinking about bpatchers and GUIs, such a feature would benefit many, I believe. The [thispatcher] outputs a nicely structured hierarchy when getting the window states, but the idea has not been followed through. Again, Im a bit annoyed that not everything I can set through [thispatcher] I can also get!

Hope these ideas will be consered. Thanks

May 20, 2011 | 5:23 pm

In javascript, wind has a dirty property that is gettable/settable.

Also, you should be able to set up something in js that reports changes to things like window properties.

For the most part, thispatcher provides a quick and dirty way to do some things that you would otherwise need javascript to do. So although thispatcher and javascript do overlap in functionality, they will never be "equal."

What things have you found that you can do with thispatcher that you can’t do with javascript (besides what you have mentioned already)?


May 21, 2011 | 6:09 pm

I’ve actually looked into the JavaScript a bit more an perhaps I was a bit too fast with my criticism. I never noticed the get/set marks behind each property and went according what I could find on the forums or elsewhere. It just never popped into my eye, sorry. Yeah, that increases the possibilities of scripting with patch with Javascript immensly!

Though, there is no way to save the .js file with you patch (as its possible with the [coll] object) for easier distribution? I would find it handy if I could just pop open a [js] object and start scripting without creating clutter of several little .js files (just a little luxury…) :)


August 23, 2014 | 1:27 pm

I have the same problem. THISPATCHER does not work when contained in a bpatcher even when using pControl to open it. Where can we find the js that can fix this? Im surprised THISPATCHER does not work when the patch can be opened with PCONTROL. Going to report this to developers.

August 23, 2014 | 11:25 pm

Im surprised THISPATCHER does not work when the patch can be opened with PCONTROL.

if you report things to developers, do be clear about exactly what it is you’re trying to report. according to your words, ‘thispatcher’ doesn’t work at all in a bpatcher.
but i’ve attached a patch-set that proves that it does.

if you are then wondering why you can’t specifically open a bpatcher using thispatcher the way it normally does same as pcontrol(which is only a very small aspect of what thispatcher is actually used for), my honest answer is this:
That’s a very unwise use of bpatcher(it ends up simply opening in a separate window with pcontrol… doesn’t make much sense to use a bpatcher in such a case).
Put the patch in a subpatcher(or abstraction), then use pcontrol or thispatcher as usual… bpatcher’s are for when you want a modularly designed interface embedded within a larger interface… if you want to show or hide the bpatcher within that interface, a better way is to hide the bpatcher itself using thispatcher outside of it, also shown in the attachment.

if i’ve misunderstood, though, my apologies in advance and feel free to clarify :)

August 24, 2014 | 7:07 am

Definitely makes sense. I understand what difference between the Bpatcher and patcher. I am using the Bpatcher to present a view and allow the user to open the Bpatcher in a seperate with PCONTROL. Now when the bpatcher opens with Pcontrol I need the window to be able to contrain in size. THISPATCHER only seemed to work with Zoom & Offset messages. I could be wrong.

Viewing 6 posts - 1 through 6 (of 6 total)