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…) :)


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