robenkleene

The subject line probably captures it well but what I am looking for is a way to send a value via pattrforward to all instances created by a poly~.

When I use something like "pattrforward polyinstance::namedobject" it only sends the value to the first instance.

I have found a couple of methods for working with poly~ instances:

1. With pattrforward, you can specify an instance number by appending it after a period in the object path. I.e. "pattrforward polyinstance.3::namedobject" would send to instance number 3.

2. If you preceded a message with "target 0" and pass it into a poly~ inlet (by using "target 0, $1" for example), then that message will be sent to all instances.

Neither of these solutions works well for me. The first would require writing lots of code to leverage, and the second would take adding 30 inlets to a poly object.

Any ideas? If anyone knows any other methods for getting information into all of the poly~ instances at once that would be very helpful to me.

Thanks in advance for any ideas you might have!!

send-via-pattrforward-to-all-poly-instances

Since the dataspace is global, putting a humble 

"receive foo" object in the patch loaded into a 

poly~ will let you use an equally humble "send 

foo" object to send the same data to all instances. I 

can't believe that this is what you're asking. 

Since the dataspace is global, putting a humble 
"receive foo" object in the patch loaded into a 
poly~ will let you use an equally humble "send 
foo" object to send the same data to all instances. I 
can't believe that this is what you're asking. 
Could you try it again?


Receive being global is the problem with using it. Check me if I am wrong, but if I use receive then multiple instances of my patch will interfere with each other correct? That is why I am using pattrforward in the first place.

I just realized my saying "multiple instances of my patch will interfere with each other" in that last comment could be interpreted as contradicting what my initial question. So just to clarify: I want to be able to run two seperate versions of the same top-level patch simultanously, without them interfering with each other. (I.e. two seperate versions of the same patch that each contain their own poly~s). That is why I am using pattrforward.

Anyway this all touches on the root of a consistant problem I've been having with Max: sending things around inside the heirarchy of a patch without making what you are sending global to the Max *environment* (which brings up all kinds of problems: afore mentioned multiple instances of the patch interfering with each other, or even totally different patches interfering with each other if they have the same variable names) seems strangely difficult.

Explain to me why solution 2 requires the addition of 30 inlets to 

poly~? If you're trying to send a message to all poly~ instances, 

targeting instance 0 and then sending a message is the way to go.

The pattr design disallows targeting multiple objects from a single 

name. If names weren't unique, getvalueof() would have no meaning. I 

suppose I could imagine a special case, where an undecorated 

poly~object's name, when used in a setvalueof() context, would 

iterate through all poly~s, but as you might imagine, that's neither 

simple to program, nor to document. For the time being, it will 

Am 19.06.2007 um 07:13 schrieb Roben Kleene:

> 2. If you preceded a message with "target 0" and pass it into a 

> poly~ inlet (by using "target 0, $1" for example), then that 

> Neither of these solutions works well for me. The first would 

> require writing lots of code to leverage, and the second would take 

Explain to me why solution 2 requires the addition of 30 inlets to  
poly~? If you're trying to send a message to all poly~ instances,  
targeting instance 0 and then sending a message is the way to go.

The pattr design disallows targeting multiple objects from a single  
name. If names weren't unique, getvalueof() would have no meaning. I  
suppose I could imagine a special case, where an undecorated  
poly~object's name, when used in a setvalueof() context, would  
iterate through all poly~s, but as you might imagine, that's neither  
simple to program, nor to document. For the time being, it will  
remain as-is.

> 2. If you preceded a message with "target 0" and pass it into a  
> poly~ inlet (by using "target 0, $1" for example), then that  
> message will be sent to all instances.
>
> Neither of these solutions works well for me. The first would  
> require writing lots of code to leverage, and the second would take  
> adding 30 inlets to a poly object.


Thanks for your response. The reason solution #2 would need 30 inlets because I have 30 different values that I want to transfer from the top-level patch into the poly~ instances.

There are so many values to pass in because poly~ instance contains the following synthesizer sound processing processing chain: user selectable oscillators+noise -> a low-pass filter -> an amplifier adsr, and an lfo. Each of these has the usual user-adjustable parameters. The top-level of my patch contains the user-interface and the poly~ instances contain the MSP sound objects. So the values from the user-interface have to get into the poly~ instances some how.

I believe that all of these sound objects must be located inside the poly~ instances (despite the fact that they should always have the same values across all voices) because they need to be triggered by each new note and their output needs to be kept separate for each voice. I.e. each voice needs it's own adsr envelope because each adsr can only handle one envelope at a time. (Correct me if I am wrong on this point, I am just thinking through my reasoning for choosing the structure I did. Obviously if I can move any of these objects outside of the poly instances then that would be an improvement -- (because it means less inlets on the poly, lower processor load, and simpler structure all-around)).

It sounds like "target 0" or global send and receives are the only ways to get data into all poly~ instances at once?

To give some idea of what I am trying to produce, here is a screenshot of Subtractor which is one of the synths that my Max/MSP project is based on:

http://www.audionet.sk/Nc/Clanky/1061284776/obr15.jpg

If my assumptions in the third paragraph are correct, then practically every control on Subtractor's interface would have to be sent via an inlet into the poly, hence a poly with 30 or so inlets.

Thanks a lot for any input you might have!

Why don't you prepend the value of each control with a descriptive 

name, and the use a route object inside the poly~ to get the tagged 

message to the correct object? Then you can use target 0 and only 

Am 20.06.2007 um 04:05 schrieb Roben Kleene:

> If my assumptions in the third paragraph are correct, then 

> practically every control on Subtractor's interface would have to 

> be sent via an inlet into the poly, hence a poly with 30 or so inlets.

Why don't you prepend the value of each control with a descriptive  
name, and the use a route object inside the poly~ to get the tagged  
message to the correct object? Then you can use target 0 and only  
need 1 inlet.

[dial]
|
[prepend dial_1]
|
[pattrforward the_poly]

|
[route dial_1 dial_2 blah_blah]
|
[cycle~]

> If my assumptions in the third paragraph are correct, then  
> practically every control on Subtractor's interface would have to  
> be sent via an inlet into the poly, hence a poly with 30 or so inlets.


> Neither of these solutions works well for me. The first would require

> writing lots of code to leverage, and the second would take adding 30

The first would need you to build a little wrapper with an uzi which is 

some code but not lots of code, the second requires not 30 inputs, but 

30 messages which you could route then to its place inside the poly.

> Any ideas? If anyone knows any other methods for getting information

> into all of the poly~ instances at once that would be very helpful to

[polyforward NoOfInstances NameOfPoly~ NameOfObject]:

Roben Kleene schrieb:
> Neither of these solutions works well for me. The first would require
> writing lots of code to leverage, and the second would take adding 30
> inlets to a poly object.

The first would need you to build a little wrapper with an uzi which is 
some code but not lots of code, the second requires not 30 inputs, but 
30 messages which you could route then to its place inside the poly.

> Any ideas? If anyone knows any other methods for getting information
> into all of the poly~ instances at once that would be very helpful to
> me.

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Why not include an argument at the beginning of the name for each receive object? For example, have [receive #1_receiveName]. Then just use different number for the argument in each instance of the poly~ patch.

I like to use a slightly more complicated naming system for my sends and receives, using #1_patchername_receiveName. Ive never run into any problems with conflicting sends this way.

Why not include an argument at the beginning of the name for each receive object? For example, have [receive #1_receiveName]. Then just use different number for the argument in each instance of the poly~ patch. 

I like to use a slightly more complicated naming system for my sends and receives, using #1_patchername_receiveName. Ive never run into any problems with conflicting sends this way.


Thanks for all the great suggestions everyone!

I'll try some of these methods out and see what I come up with.

> The top-level of my patch contains the user-interface and the poly~

> instances contain the MSP sound objects. So the values from the

> user-interface have to get into the poly~ instances some how.

Just give the top-level UI-elements names like myParam, then place a 

corresponding pattr into the poly~ and bindto the parent::myParam 

That should be your solution, doesn't even need any patch cords...

Roben Kleene schrieb:
> The top-level of my patch contains the user-interface and the poly~
> instances contain the MSP sound objects. So the values from the
> user-interface have to get into the poly~ instances some how.

Just give the top-level UI-elements names like myParam, then place a 
corresponding pattr into the poly~ and bindto the parent::myParam 
top-level UI-element...

Send via pattrforward to all poly~ instances?