Forums > MaxMSP

script creates pattr -> bindto: doesn't work

January 13, 2007 | 2:50 pm

The latest episode of ‘squeezing the most out of pattr’..
*jingle*

I create a new pattr and immediately set and print its value. That works.

I create a new pattr and immediately try to bind another pattr to it. That fails.

Does anyone know why? Steps to reproduce are in the patch.

Thanks,
Mattijs

save as "TS.add.js":

autowatch = 1;
inlets = 1;
outlets = 1;

function anything()
{
var a = patcher.getnamed("receive");
var b = patcher.newdefault(20, 60, messagename, arguments[0]);
patcher.connect(a, 0, b, 0);
}

save as whatever you like:

#P comment 147 242 68 9109513 4) now it does;
#P comment 95 158 118 9109513 2) delete the new [pattr yo];
#P comment 120 200 100 9109513 3) this doesn’t work;
#P message 153 75 41 9109513 pattr yo;
#P message 230 242 41 9109513 pattr yo;
#P message 97 242 47 9109513 bindto yo;
#P newex 97 284 26 9109513 print;
#P button 97 200 15 0;
#P newex 97 219 27 9109513 t b b;
#P newex 97 262 40 9109513 pattr;
#X prestore 1 0 0;
#P objectname u977000002;
#P newex 230 262 57 9109513 js TS.add.js;
#P newex 96 117 26 9109513 print;
#P newex 13 31 31 9109513 r blue;
#P objectname receive;
#P button 96 33 15 0;
#P newex 96 52 32 9109513 t 10 b;
#P newex 96 95 54 9109513 grab 1 blue;
#P objectname oimf;
#P newex 153 95 57 9109513 js TS.add.js;
#P comment 119 33 93 9109513 1) this prints out ’10′;
#P connect 13 0 7 0;
#P connect 9 1 13 0;
#P connect 14 0 1 0;
#P connect 3 1 14 0;
#P connect 8 0 11 0;
#P connect 12 0 8 0;
#P connect 9 0 12 0;
#P connect 10 0 9 0;
#P connect 2 0 6 0;
#P connect 3 0 2 0;
#P connect 4 0 3 0;

xp, 4.6.2, latest pattr incremental download


January 13, 2007 | 4:15 pm

put a deferlow between the [ t b b ] and the "bindto yo" and you’re
in business.

jb

Am 13.01.2007 um 15:50 schrieb Mattijs Kneppers:

> xp, 4.6.2, latest pattr incremental download


January 13, 2007 | 5:07 pm

Quote: Jeremy Bernstein wrote on Sat, 13 January 2007 17:15
—————————————————-

Hi Jeremy, thanks for replying.

> put a deferlow between the [ t b b ] and the "bindto yo" and you’re
> in business.

That’s right, but I can’t. I need the pattr to bind before other events execute because these other events depend on the remote pattr value. The bindto event is in the middle of a queue generated by the load sequence in max that has to remain in order.

I’m still trying to understand why bindto behaves like this. Let me give it a go:

Pattr gets loaded. When it initializes and discovers the @bindto attribute, theoretically it has to go and look for the other pattr and bind to it immediately. But there is a problem. There is no way of knowing whether the other pattr is already loaded (because this depends on its position in the file, which in turn depends on the order in which the user inserted the objects). So the bindto command is deferred until the object-load stage is complete and the loadbang stage is about to begin.

When I create a pattr with scripting and I am therefore able to manually put the bindto event in the queue directly after the instantiation, the bindto message will arrive at its pattr -before- the queue surrounding the object-load stage of the new pattr finished, so binding is not yet supported.

Am I close?

Thanks for attending :)
Mattijs


January 13, 2007 | 6:44 pm

The problem is (most likely) that the pattr object doesn’t actually
get its name until a deferred instant after it’s created. This is due
to the autonaming system we have in place (whereby pattr poo is named
poo[1] if another pattr poo is already in the patch) — the box has
no name until after the initial object load, so we can’t assign/
adjust the name immediately.

Hopefully you can re-jigger your patch so that a deferlow fits into
the overall structure!

jb

Am 13.01.2007 um 18:07 schrieb Mattijs Kneppers:

> Am I close?


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