bensabey

Is it possible to send a different signal to each instance of the patch in poly~ ?

multiple-signal-inputs-into-poly

I haven't tried this yet, but I think you should be able to use selector~ in connection with thispoly~. Connect all your signals to selector~ and the thispoly~ will give you the instance number and let the desired audio through...

Thanks! Yes! I got that to work (in principle). Now I also want to send different and constantly changing messages to each instance of the patch. Any chance that is possible? (I've already tried packing a list of messages into message boxes that each begin with a target value but have not had great results yet. Am I on the right track?)

I'm actually doing all of this in order to try to make use of the parallel option in poly~ since the patch is not performing well at the moment. I am using four instances of gigaverb~ and a lot of sample playback and I'm running at near 50% CPU at times.

Thanks!  Yes! I got that to work (in principle).  Now I also want to send different and constantly changing messages to each instance of the patch.    Any chance that is possible?  (I've already tried packing a list of messages into message boxes that each begin with a target value but have not had great results yet.  Am I on the right track?) 

I'm actually doing all of this in order to try to make use of the parallel option in poly~ since the patch is not performing well at the moment.  I am using four instances of gigaverb~ and a lot of sample playback and I'm running at near 50% CPU at times.


Never mind. I figured it out. But I am still working to see if poly~ can reduce the CPU load and fix my performance problems.

Never mind.  I figured it out.  But I am still working to see if poly~ can reduce the CPU load and fix my performance problems.

I assume you know about muting instances of poly~. 

I have never tried threading, but I remember seeing several posts about it. Search around the forum and I am sure you will find good advice and maybe some patches as well.

I assume you know about muting instances of poly~. 
I have never tried threading, but I remember seeing several posts about it. Search around the forum and I am sure you will find good advice and maybe some patches as well.


of course for 4 or 5 source signals only one can just use different 

inputs, but using a selector~or gate~ inside the instances wont help 

much, because you can not connect more than one signal to one inlet.

what will work great is to use send~ and receive~: you can have 35

different receive~ objects inside a poly and choose another one in 

if you dont mind the little delay it produces you can also just use

or even better, put all the [receive] or [receive~] objects in your 

poly in a sub-poly so that you can mute those which you dont want, 

and they will need zero CPU. this way you can also easily enable more

than one input in a voice, think "matrix mixer".

   [poly~ subpoly~] -> [r first-signal]

   [poly~ subpoly~] -> [r second-signal]

   [poly~ subpoly~] -> [r third-signal]

of course for 4 or 5 source signals only one can just use different 
inputs, but using a selector~or gate~ inside  the instances wont help 
much, because you can not connect more than one signal to one inlet. 

what will work great is to use send~ and receive~: you can have 35
different receive~ objects inside a poly and choose another one in 
any voice.

if you dont mind the little delay it produces you can also just use
[s] and [r] to save CPU. 
or even better, put all the [receive] or [receive~] objects in your 
poly in a sub-poly so that you can mute  those which you dont want, 
and they will need zero CPU. this way you can also easily enable more
than one input in a voice, think "matrix mixer".

[s first-signal] 
[s second-signal] 
[s third-signal]

[poly~ mainpoly~]
   [poly~ subpoly~] -> [r first-signal]
   [poly~ subpoly~] -> [r second-signal]
   [poly~ subpoly~] -> [r third-signal]


I could be wrong, but I thought I remember hearing that using send~ or send with [poly~] could cause problems. I imagine this is only an issue if you are using the multithreading options.

Depending on the complexity of your [poly~] patch, you could waste CPU with all the [in~] objects going to a [select~] because I believe the input/output from [poly~] still happens in the main thread. To reduce the number of signals needed in each subpatch, and idea I came up for output instead of using a [gate~] (same concept would work for input) is to not connect anything in to input or output in your [poly~] patch and to use JavaScript to script the in/out connections needed by each instance. I never got around to a serious test to see if this optimization was actually worth it. Now that you have reminded me of it, I will look into doing a more real test this weekend. One thing to watch out for with this technique: if you edit the patch and save it after the scripted connections have been made, you could run into problems with extra connections being created by the script the next time you run the patch.

Depending on the complexity of your [poly~] patch, you could waste CPU with all the [in~] objects going to a [select~] because I believe the input/output from [poly~] still happens in the main thread. To reduce the number of signals needed in each subpatch, and idea I came up for output instead of using a [gate~] (same concept would work for input) is to not connect anything in to input or output in your [poly~] patch and to use JavaScript to script the in/out connections needed by each instance.  I never got around to a serious test to see if this optimization was actually worth it.  Now that you have reminded me of it, I will look into doing a more real test this weekend.  One thing to watch out for with this technique: if you edit the patch and save it after the scripted connections have been made, you could run into problems with extra connections being created by the script the next time you run the patch.


multiple signal inputs into poly~