Forums > Javascript

how to use this.patcher.message method… to send message to ANother patcher?

Apr 05 2011 | 8:18 pm

how to use this.patcher.message method… to send message to ANother patcher?

I have a subpatcher and want to send message from it, to the parent patcher.
I tried to put a global name on the parent patcher (main is a pretty name) and I tried the (probably awful) main.patcher.message()


any tip?

Apr 05 2011 | 9:44 pm

You can’t use message() with a patcher object in javascript, it will only work for maxobj javascript objects within a patcher. Do you have an example patch, I’d be happy to have a look. Here’s an example that might help with a brief explanation which might shed some light on the subject:

this.patcher.parentpatcher.getnamed("objname").message("do this thing");

this.patcher: where we are right now.
.parentpatcher: get the patcher object of the containing patcher.
.getnamed("objname"): get the maxobj object with scripting name "objname" in the parent patch.
.message("do this thing"): send this message to the afore-mentioned object.

Apr 05 2011 | 9:50 pm

ok you just answered (parentpatcher)
I abused by saying that, but I know Maxobj is a representation of the patcher in JS.

In several line, you just taught me how to navigate in that case :)

thanks a lot Luke,

Aug 11 2011 | 4:15 pm

That’s really helpful Luke. Is there a way to access subpatches as well?

Aug 12 2011 | 7:29 pm

You could, of course, add another outlet to your js object, connect it to a dedicated inlet in your subpatcher, and connect that inlet inside the subpatcher to a [thispatcher] object.

That buys you pretty much everything sending messages from inside your js can do, with the added advantage that you have some kind of visible connection in your patch reminding you (a year later, when you have to make changes to the patch) that you’re doing dynamic scripting from inside the js.

Invisible messages can make patch maintenance a nightmare. Arguably more so than the dreaded goto statement in procedural programming languages. They can be a powerful tool, but you can also shoot yourself in the knee with them.

If I seem a little obsessive about this, I have in the course of my career taken on maintenance for several large projects with upwards of 20 js files generating dynamic stuff, sometimes in great-grandparent patchers. It’s hell and mostly could be done in other, more maintainable ways.

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

Forums > Javascript