Forums > MaxMSP

real fast patcher arguement question

February 9, 2009 | 7:23 am

hey i remember that isnide a patcher you could set up a variable that would be replaced (effectively) by the corresponding arguement in the patcher so that $1 would be replaced by the first arguement/ etcetera. Could someone just remind me how to do this real fast? thx


February 9, 2009 | 8:22 am

hi,

#0 is the instance number (pid)
#1 is the first arg, #2 the second one, etc…

cheers

g

2009/2/9 eli

>
> hey i remember that isnide a patcher you could set up a variable that would
> be replaced (effectively) by the corresponding arguement in the patcher so
> that $1 would be replaced by the first arguement/ etcetera. Could someone
> just remind me how to do this real fast? thx
> –
> http://www.myspace.com/theblackpeacock NOISE BIATCH!
>


February 9, 2009 | 9:58 am

If you mean in abstractions, it’s simply a matter of using #1, #2 etc. in the abstraction to be replaced by the corresponding arguments.
eg. if you have an and in your , giving the abstraction arguments of 17 & 23 will instantiate an and respectively.
#0 will generate a unique number so if eg. if you wanted to generate an buffer~/groove~ pair unique to a particular instance of your abstraction, you could call them and ,
cheers
Roger

— On Mon, 9/2/09, eli

wrote:

> From: eli

> Subject: [maxmsp] real fast patcher arguement question
> Date: Monday, 9 February, 2009, 7:23 AM
> hey i remember that isnide a patcher you could set up a
> variable that would be replaced (effectively) by the
> corresponding arguement in the patcher so that $1 would be
> replaced by the first arguement/ etcetera. Could someone
> just remind me how to do this real fast? thx
> –
> http://www.myspace.com/theblackpeacock NOISE BIATCH!


February 9, 2009 | 3:30 pm

This is perhaps a case of me being exceptionally
cautious when seeing someone use the word "instance"
to describe working with #0, but I’ll say it anyway:

Using #0 gives you a unique *global* thing to refer
to in your bpatcher/subpatcher. Since some people
out there are accustomed to using the word "instance"
to refer to an instance of a patch loaded by the
poly~ object, I wanted to point out that #0 won’t
give you the "instance" number of something loaded
in a poly~.

To do that, you’d use the thispoly~ object and some
dynamic send/receive logic of your own devising
[or the forward object, if you'd prefer. That's up
to you].

A simpler approach would be to rely on the "target"
message to the poly~ object itself.

I realize that for many of you, this is old hat. But
that may not be so for everyone.


February 14, 2009 | 7:57 am


February 14, 2009 | 9:48 am

Just chiming in on the send/receive logic comment – it’s really not hard!

loadbang -> thispoly -> sprintf set sendname%i -> send

for the receives, it’s the same, just a receive instead of a send, obviously.

This’ll make each poly instance have a send that sends to ‘sendnameX’, where X is the number of the instance. So instance one sends out sendname1, instance 2 is sendname2, etc.

This is very, very useful if you’re using any of the Hi-res buffer-referencing objects (such as hr.play~ or hr.wave~) in a parallel processing poly patch. There’s an issue with them where they wont’ release the buffer when running parallel — just enclose them in a poly that’s not running parallel, and let the rest of your poly run parallel!


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