Nikolas K

I know that poly~ voices can change dynamically, but every time I do this, as I understand the instances are rebuild from 0, all of them.

So any data fed to them are lost. Is there any way to dynamically change the poly~ voices without restarting the already allocated ones?

I know that poly~ voices can change dynamically, but every time I do this, as I understand the instances are rebuild from 0, all of them.
So any data fed to them are lost. Is there any way to dynamically change the poly~ voices without restarting the already allocated ones?

change-poly-voices-without-reinitiallizing-the-ones-already-existing

use 2 of the same poly~ and crossfade to mask the change in #-of-voices(the idea by-design behind poly~ is to allow you to setup the 

 voices you'd need from the start and only use those voices as you need them... anything else is inefficient(this design stems from what hardware synth makers have found to be most efficient throughout history...) in the digital/software world it's still the most efficient to think in terms of this: it's more efficient(not to mention 'creative') to figure out the most you'd need from the start and stay within that. also a good mindset to have when consuming resources in the real world too ;D)

...and I know you've been around long enough to know all that already, I'm just posting to relate my world politics bullshit to the whole issue in that last sentence about consuming resources in the real world there >:)

"Ask not what your poly~ can do for you, but what you can do for your poly~!"

"The only thing we have to allocate, is allocation itself!"

"I have a dream! ...someday poly~ will not be judged by the amount of its voices, but by the content and character of its source-patch!"

use 2 of the same poly~ and crossfade to mask the change in #-of-voices(the idea by-design behind poly~ is to allow you to setup the maximum voices you'd need from the start and only use those voices as you need them... anything else is inefficient(this design stems from what hardware synth makers have found to be most efficient throughout history...) in the digital/software world it's still the most efficient to think in terms of this: it's more efficient(not to mention 'creative') to figure out the most you'd need from the start and stay within that. also a good mindset to have when consuming resources in the real world too ;D)

...and I know you've been around long enough to know all that already, I'm just posting to relate my world politics bullshit to the whole issue in that last sentence about consuming resources in the real world there >:)
 "Ask not what your poly~ can do for you, but what you can do for your poly~!"
"The only thing we have to allocate, is allocation itself!"
"I have a dream! ...someday poly~ will not be judged by the amount of its voices, but by the content and character of its source-patch!"


Or, depending on what you want to achieve, use just one [poly~] with the maximum amount of voices, and use a... [poly] outside of your [poly~] to allocate voices. Change the number of voice of [poly] as desired.

"Use the poly~ for knowledge and defense, never for attack."

While my idea of a better poly~ future agrees to Raja's opinions and problem thinking/dealing,

I must say the the "polyception" Jean-Francois is suggesting, is something that is hadn't thought of (At least for that use). I have to try it...

I know the max number of instances that might be needed. It is a dynamic interface, so the voices needed could be between 1 and 150(?). I could load 150 voices from the beginning but I want to try and not force the user to wait that time unless he needs to.

Well....
While my idea of a better poly~ future agrees to Raja's opinions and problem thinking/dealing,
I must say the the "polyception" Jean-Francois is suggesting, is something that is hadn't thought of (At least for that use). I have to try it...

I know the max number of instances that might be needed. It is a dynamic interface, so the voices needed could be between 1 and 150(?). I could load 150 voices from the beginning but I want to try and not force the user to wait that time unless he needs to. 

(I sometimes wish there was an "upvote post" feature here)

Getting back to those who are interested, I went with loading the maximum voices that might be needed (like Raja / Willy pointed out at the top), since its not so time consuming and if placed in the right moment (user gets a "loading" screen) it feels natural, not like the app is lagging.

Having to poly~s, I think might be a good solution when there is a massive voice variation, and lots and lots of voices.

But for now, having an upper voice limit suggest that creating the maximum needed voices is the best approach.

Getting back to those who are interested, I went with loading the maximum voices that might be needed (like Raja /  Willy pointed out at the top), since its not so time consuming and if placed in the right moment (user gets a "loading" screen) it feels natural, not like the app is lagging. 

Having to poly~s, I think might be a good solution when there is a massive voice variation, and lots and lots of voices.
But for now, having an upper voice limit suggest that creating the maximum needed voices is the best approach.

I'm dealing with this problem now too; particularly with a lot of external controllers.

When working with 4 voices by default and then occasionally deciding I'd like to hear the patch with say 16 I send a [prepend voices] message, but it triggers all the [loadbang]s I have inside the [poly~] patch and sets my lovely designed synth voice back to its defaults (which for a while was silence - driving me insane).

My solution was to use a [trigger] connected to the 'voices' message that would then hit a load of [zl.reg]s that store the most recent settings - they would work like upper level [loadmess] messages to apply the same settings to the new voices created.

I'm dealing with this problem now too; particularly with a lot of external controllers.

When working with 4 voices by default and then occasionally deciding I'd like to hear the patch with say 16 I send a [prepend voices] message, but it triggers all the [loadbang]s I have inside the [poly~] patch and sets my lovely designed synth voice back to its defaults (which for a while was silence - driving me insane).

good solution, which is also useful in other contexts.

it still seems easier to just start with 16 voices but only use 4 of them.

my poly patchers are all dsp-off by default (and voicing is controlled from outside.)


good solution, which is also useful in other contexts.

it still seems easier to just start with 16 voices but only use 4 of them.

my poly patchers are all dsp-off by default (and voicing is controlled from outside.)


Though I'd still like to try what everyone is suggesting, I don't understand how I only use 4 of my 16 voices? Is the idea to write my own kind of 'steal' function?

Every time a new note message is sent to [poly~] it's going to activate the next available voice, so after 4 it'll jump to 5 - but I don't want to use 5 right?

So I can use 'target' to address the next voice I want which is likely voice 1. I've knocked up a little sketch that'll cycle through them doing just this.

if I'm doing something like sending different length envelopes to different voices, voice 1 might still be running, but voice 2 might be free - how do I get this feedback from [poly~]?

I saw some messages like 'mutemap' and 'busymap' which I guess I could use to check if a voice is in use before sending the next note message to it, but I couldn't find a way to get the result out of the poly~

Cheers! 
Though I'd still like to try what everyone is suggesting, I don't understand how I only use 4 of my 16 voices? Is the idea to write my own kind of 'steal' function?

Every time a new note message is sent to [poly~] it's going to activate the next available voice, so after 4 it'll jump to 5 - but I don't want to use 5 right?

So I can use 'target' to address the next voice I want which is likely voice 1. I've knocked up a little sketch that'll cycle through them doing just this. 

But what if I don't want to steal voice?
if I'm doing something like sending different length envelopes to different voices, voice 1 might still be running, but voice 2 might be free - how do I get this feedback from [poly~]?

if you go the "target" route (it is always recommended not to mix automatic with custom voice stuff), enabling only a few voices is really easy.

in the most simple scenario you would just send "target 1, mute 0" or ""target 3, mute 1" to the poly~ (and have a thispoly~ inside.)

if you want the dsp on/off to happen inside, you can do the same also with the usual "note on turns a poly on", "end of the envelope turn it off" or "turn it off again when 2 seconds passed" thing.

"But what if I don't want to steal voice?"

can get more complicated with "target". you will have to send the "i am done, i go to sleep more again" info from all voices out of the poly~, so that the info is available in your main patch. 

eventually you can also precalculate the end of the voice from outside (if it is really only a simple envelope without random and modulation input)


if you go the "target" route (it is always recommended not to mix automatic with custom voice stuff), enabling only a few voices is really easy.

in the most simple scenario you would just send "target 1, mute 0" or ""target 3, mute 1" to the poly~ (and have a thispoly~  inside.)

if you want the dsp on/off  to happen inside, you can do the same also with the usual "note on turns a poly on", "end of the envelope turn it off" or "turn it off again when 2 seconds passed" thing.

"But what if I don't want to steal voice?"

can get more complicated with "target". you will have to send the "i am done, i go to sleep more again" info from all voices out of the poly~, so that the info is available in your main patch. 

eventually you can also precalculate the end of the voice from outside (if it is really only a simple envelope without random and modulation input)


Change poly~ voices, without reinitiallizing the ones already existing.