acsmith

I seem to remember that there's a way to do [r looptimes] (for

example) but have it be patcher-specific, so that I can load more than

one instance of my patch and not have that run into trouble. Could

always just use patch cables, but I'm just wondering this for future

reference. It's something weird like [r looptimes%] or whatever,

right? I can't find it in the reference...

Hey all,
I seem to remember that there's a way to do [r looptimes] (for
example) but have it be patcher-specific, so that I can load more than
one instance of my patch and not have that run into trouble.  Could
always just use patch cables, but I'm just wondering this for future
reference.  It's something weird like [r looptimes%] or whatever,
right?  I can't find it in the reference...

patcher-specific-sendreceives

On Dec 14, 2008, at 9:30 PM, Andrew C. Smith wrote:

> It's something weird like [r looptimes%] or whatever,

#0 gets substituted with a unique identifier. It has to be a the 

beginning of a symbol, though, so your example would have to be [r 

> It's something weird like [r looptimes%] or whatever,
> right?

#0 gets substituted with a unique identifier. It has to be a the  
beginning of a symbol, though, so your example would have to be [r  
#0_looptimes] sor similar.

Chris Muir
cbm@well.com	
http://www.xfade.com

i suppose your talking about working with poly~ instances.

to have your instance send named according to it's instance number,

names receive objects inside the poly~ patch accordingly.

loadbang
|
thispoly
|
sprintf %ld_looptimes
|
send (without name)

loadbang
|
thispoly
|
sprintf %ld_looptimes
|
(message) set $1
|
r (without name)

Thanks, that's very helpful. Would you happen to know if messages are sent from (or received by) each voice in any particular order? Does the same technique work for audio signals also?

Thanks, that's very helpful. Would you happen to know if  messages are sent from (or received by) each voice in any particular order? Does the same technique work for audio signals also?


Nope, I was just using embedded patchers, like [looper~] where

looper~.maxpat is in the search path. The #0_ trick worked

beautifully. Always good to know two ways, though--I'll try the

Ernest: the #0 thing works for audio signals ([receive~ ...]), and I

would assume the sprintf thing does, too, since "set" does the same

thing for both. This is for send/receives INTERNAL to each voice (or

instance of an embedded patcher), so that it doesn't bleed from one

On Mon, Dec 15, 2008 at 9:24 AM, Ernest wrote:

> Thanks, that's very helpful. Would you happen to know if messages are sent from (or received by) each voice in any particular order? Does the same technique work for audio signals also?

Nope, I was just using embedded patchers, like [looper~] where
looper~.maxpat is in the search path.  The #0_ trick worked
beautifully.  Always good to know two ways, though--I'll try the
sprintf thing some other day with poly~.

Ernest: the #0 thing works for audio signals ([receive~ ...]), and I
would assume the sprintf thing does, too, since "set" does the same
thing for both.  This is for send/receives INTERNAL to each voice (or
instance of an embedded patcher), so that it doesn't bleed from one
patch to another.

On Mon, Dec 15, 2008 at 9:24 AM, Ernest  wrote:
>
> Thanks, that's very helpful. Would you happen to know if  messages are sent from (or received by) each voice in any particular order? Does the same technique work for audio signals also?
>


Oh. I was hoping for a way to get a separate signal from each instance of a poly patch out into the parent patch. This is not possible? I guess if, on a multiplier object, the multiplicand of all the instances *except* 1 could be set to o, then it could there could be multiple sends, one for each instance.

Patcher-specific send/receives