Forums > MaxMSP

patcherargs in nested abstractions – what's happening here?

June 21, 2006 | 4:39 am

I’ve made a little send abstraction [s.] that concatenates multiple arguments into a send name, ie [s. A B] makes [s A.B] inside the abstraction, using a loadbanged patcherargs object.

This works fine when used in a patch or subpatches inside that, but when it’s used inside another abstraction [s.test] that is instantiated in the parent patch, I’m getting doubled messages.

If I concatenate conventional numbered arguments for the [s.] abstraction, ie [loadmess #1 #2], it works correctly, and I have been using that for some time. But I want to allow for an arbitrary number of arguments, thus the use of patcherargs.

So it’s something to do with patcherargs when used in nested abstractions. What’s happening? Is it supposed to happen? Any workarounds?

test patch:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 294 221 50 196617 print E.F;
#P newex 294 192 50 196617 r E.F;
#P comment 293 58 61 196617 this doesn’t;
#P message 200 89 28 196617 stop;
#P button 178 89 15 0;
#P newex 178 126 61 196617 metro 999;
#N vpatcher 20 74 620 474;
#P inlet 81 121 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 81 162 50 196617 s. C D;
#P connect 1 0 0 0;
#P pop;
#P newobj 178 155 61 196617 p subpatch;
#P newex 74 219 50 196617 print AB;
#P newex 74 190 50 196617 r A.B;
#P message 96 90 28 196617 stop;
#P button 74 90 15 0;
#P newex 74 127 61 196617 metro 999;
#P newex 74 155 50 196617 s. A B;
#P newex 179 221 50 196617 print CD;
#P newex 179 192 50 196617 r C.D;
#P message 315 90 28 196617 stop;
#P button 293 90 15 0;
#P newex 293 127 61 196617 metro 999;
#P newex 293 155 71 196617 s.test E F;
#P comment 109 58 100 196617 both these work fine;
#P connect 2 0 1 0;
#P connect 18 0 19 0;
#P connect 5 0 6 0;
#P connect 11 0 12 0;
#P connect 14 0 13 0;
#P connect 15 0 14 0;
#P connect 16 0 14 0;
#P connect 4 0 2 0;
#P connect 3 0 2 0;
#P connect 10 0 8 0;
#P connect 9 0 8 0;
#P connect 8 0 7 0;
#P window clipboard copycount 20;

[s.test] abstraction:

#P inlet 103 167 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 103 198 50 196617 s. $1 $2;
#P connect 1 0 0 0;
#P window clipboard copycount 2;

[s.] abstraction:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 268 83 58 196617 separator .;
#P newex 198 37 50 196617 loadbang;
#P newex 198 82 64 196617 patcherargs;
#P newex 198 124 50 196617 tosymbol;
#P inlet 30 37 15 0;
#P objectname inlet;
#P newex 31 297 24 196617 b 1;
#P message 31 320 157 196617 script connect inlet 0 snd 0;
#N thispatcher;
#Q end;
#P newobj 198 361 64 196617 thispatcher;
#P newex 198 254 270 196617 prepend script new snd newex 30 60 150 196617 s;
#P connect 7 0 6 0;
#P connect 7 0 8 0;
#P fasten 0 0 3 0 203 285 36 285;
#P connect 0 0 1 0;
#P fasten 2 0 1 0 36 349 203 349;
#P connect 5 0 0 0;
#P connect 6 0 5 0;
#P connect 8 0 5 0;
#P connect 3 0 2 0;
#P window clipboard copycount 9;


June 21, 2006 | 8:25 am

John Pitcairn a écrit :
> I’ve made a little send abstraction [s.] that concatenates multiple arguments into a send name, ie [s. A B] makes [s A.B] inside the abstraction, using a loadbanged patcherargs object.
>
> This works fine when used in a patch or subpatches inside that, but when it’s used inside another abstraction [s.test] that is instantiated in the parent patch, I’m getting doubled messages.
>
> If I concatenate conventional numbered arguments for the [s.] abstraction, ie [loadmess #1 #2], it works correctly, and I have been using that for some time. But I want to allow for an arbitrary number of arguments, thus the use of patcherargs.
>
> So it’s something to do with patcherargs when used in nested abstractions. What’s happening? Is it supposed to happen? Any workarounds?
>

Hi John

when you 2xClick on [r E.F] the popup shows 2 [s E.F].

I think you’re object is instantiated once when the patch s.test is
loaded and another time when max give it’s arguments to s.test,
though I can’t manage to see anything in the max window. weird, maybe
someone else has an answer for this behaviour ?

A workaround is to delete you’re object before creating a new one
(though in you’re saved abstraction there is no object "snd")
so create a dummy one in you’re abstraction, delete it, it works. see
patch below.

[s.]

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 30 61 73 196617 s AEAEAEAEA;
#P objectname snd;
#P newex 194 261 38 196617 t b s b;
#P message 268 308 85 196617 script delete snd;
#P message 268 83 58 196617 separator .;
#P newex 198 37 50 196617 loadbang;
#P newex 198 82 64 196617 patcherargs;
#P newex 198 124 50 196617 tosymbol;
#P inlet 30 37 15 0;
#P objectname inlet;
#P newex 31 297 24 196617 b 1;
#P message 31 320 157 196617 script connect inlet 0 snd 0;
#N thispatcher;
#Q end;
#P newobj 198 361 64 196617 thispatcher;
#P newex 198 221 270 196617 prepend script new snd newex 30 60 150 196617 s;
#P connect 10 2 9 0;
#P connect 7 0 6 0;
#P connect 7 0 8 0;
#P connect 9 0 1 0;
#P fasten 2 0 1 0 36 349 203 349;
#P connect 10 1 1 0;
#P connect 5 0 0 0;
#P connect 6 0 5 0;
#P connect 8 0 5 0;
#P connect 0 0 10 0;
#P connect 3 0 2 0;
#P connect 10 0 3 0;
#P connect 4 0 11 0;
#P window clipboard copycount 12;


June 21, 2006 | 9:21 am



grg
June 21, 2006 | 2:34 pm

Am 21.06.2006 um 11:21 schrieb John Pitcairn:
> Weird indeed. I did test with print statements of course, and that
> seems to indicate loadbang/patcherargs only fires once. If it’s
> somehow sending again all by itself, or the loadbang is firing twice,
> invisibly, I’d call that a bug.

hey John,

in the example you posted, all 3 versions output twice for me. I think
the scripted send object is simply created twice (sometimes). Why
loadbang patcherargs if it outputs on load anyway? Loadbanging
something that loadbangs itself turns out to be nondeterministic.

using this as "s." works for me:

cheers, g.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 328 90 58 196617 separator .;
#P newex 258 64 27 196617 t l b;
#P newex 258 39 64 196617 patcherargs;
#P newex 258 131 50 196617 tosymbol;
#P inlet 90 44 15 0;
#P objectname inlet;
#P newex 91 304 24 196617 b 1;
#P message 91 327 157 196617 script connect inlet 0 snd 0;
#N thispatcher;
#Q end;
#P newobj 258 368 64 196617 thispatcher;
#P newex 258 261 270 196617 prepend script new snd newex 30 60 150
196617 s;
#P connect 7 1 8 0;
#P fasten 2 0 1 0 96 356 263 356;
#P fasten 0 0 3 0 263 292 96 292;
#P connect 0 0 1 0;
#P connect 5 0 0 0;
#P connect 8 0 5 0;
#P connect 7 0 5 0;
#P connect 6 0 7 0;
#P connect 3 0 2 0;
#P window clipboard copycount 9;


June 21, 2006 | 10:37 pm

Huh. Yeah. From the reference manual:

"Out left outlet: A list of the parent patcher’s arguments are sent out the left outlet when the patcher is loaded."

I think perhaps the help file could use a small modification, because there’s no mention of that therein – it looks like patcherargs needs a bang to output. You wouldn’t notice the auto-output unless the Max window is visible and you’re paying attention to it.

Thanks for the help.


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