to_the_sun

For starters, I know that if your poly~ has a live.remote in it, it will stop functioning if you send the poly~ a 

message. I believe the same is true for live.observer or other API objects, is that right? However, in my current situation I have no API references inside my poly~, and I very much need to change the number of voices dynamically, but strange things seem to happen when I do. I'm trying to pin down exactly what.

One thing that seems to happen is [value] objects forget their value. And actually it seems to be more than that; it seems they lose their ability to store new values as well. Maybe it's that they lose connection to their names or something? Any insights?

Are there any other things that are known to go wrong when using the 

message? Maybe we can put together a list. It would certainly help me proceed as I attempt to choose a path forward.

For starters, I know that if your poly~ has a live.remote in it, it will stop functioning if you send the poly~ a voices message. I believe the same is true for live.observer or other API objects, is that right? However, in my current situation I have no API references inside my poly~, and I very much need to change the number of voices dynamically, but strange things seem to happen when I do. I'm trying to pin down exactly what.

 One thing that seems to happen is [value] objects forget their value. And actually it seems to be more than that; it seems they lose their ability to store new values as well. Maybe it's that they lose connection to their names or something? Any insights?

Are there any other things that are known to go wrong when using the voices message? Maybe we can put together a list. It would certainly help me proceed as I attempt to choose a path forward.


when-is-setting-the-number-of-poly-voices-dynamically-not-viable

On the poly~ reference page 'voices' is not listed under messages but under attributes. So it seems to be meant primarily for initialization and dynamic changes may be problematic, in particular if the instances are not simple functions and have different internal states.

I thnnk Broc is right, and there is a simple solutio. Most the time, you can create as many voices as your memory can support easily, then mute the ones you dont want. The only thing is, so far I havent been able to create poly~ instances in a muted state. I think you have to mute them with a loadbang or similar once they are initialized. This can create a bit of a cpu peak during launch, because everything else is starting up at the same time.

So what I do, when I need alot of instances, is set the polY~ instance to have one voice at startup. Then the first top-level lodbang sets the attribute to create the maximum number of voices I need. Then loadbangs in the poly~ subpatch mute them as soon as they are created. Then when I need the polys, I unmute them. and that stops the big CPU peaks.

If I need other things to happen which are cpu intensive, I watch the poly instance and wait for the last one to initialize. That is, I bang thispoly~ before muting it, to get the instance number, and send the instance number out a port. So say there are 100 instances. They start in sequence and out the poly~ port comes 1, 2, 3,....100.

Then I attach a "sel 100" to the poly~ objects output port, and when it bangs, I know all the polys are started up, and can send them data and so on.

They still can receive messages when muted, but the audio gets turned off by the mute. So I am also careful with TARGET 0 messages.

I thnnk Broc is right, and there is a simple solutio. Most the time, you can create as many voices as your memory can support easily, then mute the ones you dont want. The only thing is, so far I havent been able to create poly~ instances in a muted state. I think you have to mute them with a loadbang or similar once they are initialized. This can create a bit of a cpu peak during launch, because everything else is starting up at the same time. 

So what I do, when I need alot of instances, is set the polY~ instance to have one voice at startup. Then the first top-level lodbang sets the attribute to create the maximum number of voices I need. Then loadbangs in the poly~ subpatch mute them as soon as they are created. Then when I need the polys, I unmute them. and that stops the big CPU peaks. 

If I need other things to happen which are cpu intensive, I watch the poly instance  and wait for the last one to initialize. That is, I bang thispoly~ before muting it, to get the instance number, and send the instance number out a port. So say there are 100 instances. They start in sequence and out the poly~ port comes 1, 2, 3,....100. 

Then I attach a "sel 100" to the poly~ objects output port, and when it bangs, I know all the polys are started up, and can send them data and so on.  

They still can receive messages when muted, but the audio gets turned off by the mute. So I am also careful with TARGET 0 messages.


Thanks for your responses. The reason I would like to change the number of voices dynamically is right along the lines of what you're describing Ernest, and yes, I do loadbang-mute my instances and activate them only when necessary. At first my poly~ had 100 voices, but since there's so much code in it, it was causing live to lag a ton when the device loaded, and crash it entirely at times. I reduced it to 30 to alleviate this, which theoretically should be enough but there might be some rare cases where I would want more. And actually right now I'm needing to put that poly~ inside of another poly~, which should only need a few voices but again, this is a case where I can't actually determine the maximum number I would ever need. So my plan was to start them out with one or a few each, and add new ones one at a time as necessary. But like I said, altering the number of voices, even just a little while after the device loads, causes all my value objects to go dead.

I haven't had the opportunity to experiment any further yet, but I think it might be the value objects that have the prefix --- and should be coordinating with objects of the same name outside of the poly~; the three random numbers that replace the dashes must change when the poly~ reloads its voices (while those outside of the poly~ stay the same). If so, I could easily work around it, so that would be good news. I'll post back when I figure it out.

ok, I suggest using the sel object on the poly~ output to generate a bang when the last thispoly~ loads,then do your other stuff to ply~ from that, so you can be sure they are all loaded before you send them anything.

What broc said has turned out to be exactly right. The 

message causes every instance to reload in its initial state. This means counters reset, seq~s lose their contents, objects of every kind forget what messages have been sent to them, etc. etc. So in my situation I will have to leave my inner poly~ with a set number of voices, and the outer poly~ sets its voices dynamically not long after initialization.

What broc said has turned out to be exactly right. The voices message causes every instance to reload in its initial state. This means counters reset, seq~s lose their contents, objects of every kind forget what messages have been sent to them, etc. etc. So in my situation I will have to leave my inner poly~ with a set number of voices, and the outer poly~ sets its voices dynamically not long after initialization.


That said, it would still be very useful to have an argument for [poly~] to start with all voices muted, without a need for [loadbang] and workarounds. Hope the c74 guys are listening.

What would be really nice is if there was an actual message to add or subtract instances, without affecting the others that are already there.

Do you think it really is the DSP that causes it to lag upon initialization? For me the bulk of the poly~ patch is ordinary processing and there actually isn't very much DSP. The file is here

https://drive.google.com/file/d/0B7A5aMMtv17dVmZOUWxFeG5XZFk/view?usp=sharing

When is setting the number of poly~ voices dynamically NOT viable?