johnpitcairn

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?

patcherargs-in-nested-abstractions-whats-happening-here

> 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?

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 

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?
>

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.

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, 

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.

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.

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.

"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.

patcherargs in nested abstractions - what's happening here?