davidestevens

Just built a patch around a 9 voice poly~ ...

I'd now like to record each voice to a separate sfplay~ (ie one 

sfplay~ per voice). It seems to me that there are two options:

1 - put an sfrecord~ inside the poly~ so that there are 9 instances. I 

wonder if they would tend to be starting way out of sync?

2 - get the audio out of each instance separately, using send~ I would 

guess. In this case I'd have to use #0 to name all the send~s, and get 

those names out of each instance to name the receive~ objects.

My brain is a bit blown at the moment, so any comments on which might 

be the best way to do this (or alternatives), and any other thoughts, 

I'd now like to record each voice to a separate sfplay~ (ie one  
sfplay~ per voice). It seems to me that there are two options:

1 - put an sfrecord~ inside the poly~ so that there are 9 instances. I  
wonder if they would tend to be starting way out of sync?

2 - get the audio out of each instance separately, using send~ I would  
guess. In this case I'd have to use #0 to name all the send~s, and get  
those names out of each instance to name the receive~ objects.

My brain is a bit blown at the moment, so any comments on which might  
be the best way to do this (or alternatives), and any other thoughts,  
would be much appreciated.

getting-separate-audio-feeds-out-of-multivoice-poly

On 17 Feb 2009, at 18:39, Emmanuel Jourdan wrote:

>> 2 - get the audio out of each instance separately, using send~ I 

>> would guess. In this case I'd have to use #0 to name all the 

>> send~s, and get those names out of each instance to name the 

> using send~/receive~ to communicate between inside/ouside of a poly~ 

Ah yes - I knew there was a reason I wasn't sure about this. I tried 

this several years back and had all kinds of problems.

> I would recommend using multiple out~ and something like gate~ to 

route the signal to the appropriate outlet.

There are 9 stereo instances of the patcher, so that'd be 18 audio 

outlets!. To use gate~ inside the poly~ I'd need to know the instance 

number to set gate to the right outlet, which I can get from thispoly~

Hmm. Ok, i can see that working, though that's a lot of out~s! What I 

need here is a funnel for audio signals, so that I can prefix each 

audiostream with an identifier and then extract it outside the poly~.

Isn't there something like that in tap.tools? Or is it in Jamoma at 

the moment, and not yet included in tap.tools?

On 17 Feb 2009, at 18:39, Emmanuel Jourdan wrote:
>>
>>
>> 2 - get the audio out of each instance separately, using send~ I  
>> would guess. In this case I'd have to use #0 to name all the  
>> send~s, and get those names out of each instance to name the  
>> receive~ objects.
>
>
> using send~/receive~ to communicate between inside/ouside of a poly~  
> is a really bad idea because

Ah yes - I knew there was a reason I wasn't sure about this. I tried  
this several years back and had all kinds of problems.

 > I would recommend using multiple out~ and something like gate~ to  
route the signal to the appropriate outlet.

There are 9 stereo instances of the patcher, so that'd be 18 audio  
outlets!. To use gate~ inside the poly~ I'd need to know the instance  
number to set gate to the right outlet, which I can get from thispoly~

Hmm. Ok, i can see that working, though that's a lot of out~s!  What I  
need here is a funnel for audio signals, so that I can prefix each  
audiostream with an identifier and then extract it outside the poly~.

Isn't  there something like that  in tap.tools? Or is it in Jamoma at  
the moment, and not yet included in tap.tools?

But what is wrong with 18 outlets? I would think that would make for 

a more easily maintained patch (especially two years from now, when 

you have to fix something and you can't figure out what the heck this 

This could just be me, though. I always tend to prefer 

On Feb 17, 2009, at 11:55 AM, David Stevens wrote:

> There are 9 stereo instances of the patcher, so that'd be 18 audio 

> outlets!. To use gate~ inside the poly~ I'd need to know the 

> instance number to set gate to the right outlet, which I can get 

> Hmm. Ok, i can see that working, though that's a lot of out~s! What 

> I need here is a funnel for audio signals, so that I can prefix each 

> audiostream with an identifier and then extract it outside the poly~.

> Isn't there something like that in tap.tools? Or is it in Jamoma 

> at the moment, and not yet included in tap.tools?

But what is wrong with 18 outlets?  I would think that would make for  
a more easily maintained patch (especially two years from now, when  
you have to fix something and you can't figure out what the heck this  
poly-ploy accomplished...).

This could just be me, though.  I always tend to prefer  
maintainability over cleverness.

On Feb 17, 2009, at 11:55 AM, David Stevens wrote:
>
>
> There are 9 stereo instances of the patcher, so that'd be 18 audio  
> outlets!. To use gate~ inside the poly~ I'd need to know the  
> instance number to set gate to the right outlet, which I can get  
> from thispoly~
>
> Hmm. Ok, i can see that working, though that's a lot of out~s!  What  
> I need here is a funnel for audio signals, so that I can prefix each  
> audiostream with an identifier and then extract it outside the poly~.
>
> Isn't  there something like that  in tap.tools? Or is it in Jamoma  
> at the moment, and not yet included in tap.tools?
>
> David


On 17 Feb 2009, at 19:06, Darwin Grosse wrote:

Oh that's just me worrying about overworking Max - my mind hasn't 

quite caught up with what's possible with the latest computers.

I implemented ej's suggestion, and it does the trick.

Oh that's just me worrying about overworking Max - my mind hasn't  
quite caught up with what's possible with the latest computers.
I implemented ej's suggestion, and it does the trick.

>>> 2 - get the audio out of each instance separately, using send~ I 

>>> would guess. In this case I'd have to use #0 to name all the 

>>> send~s, and get those names out of each instance to name the 

>> using send~/receive~ to communicate between inside/ouside of a 

> Ah yes - I knew there was a reason I wasn't sure about this. I tried 

> this several years back and had all kinds of problems.

> > I would recommend using multiple out~ and something like gate~ to 

> route the signal to the appropriate outlet.

I have done this in the past and found it to be very CPU-demanding and 

inefficient. When you add one out ~ for each instacne, and end up 

using 9 voices, it means that for each instance, poly~ will be summing 

the output from each outlet, in effect requiring 9x9=81 additions 

happening at audio rate. I would consider making 9 instances of an 

abstraction instead. It might be more work to patch, but it will free 

Yes, there are jcom.multi.in~ and jcom.multi.out~ abstractions in 

Jamoma, but they do unfortunately not work with poly~. In general I 

would say that support for multichannel signals in Max would be one of 

my top priority whishes for a long overdue new version of MSP. Maybe I 

should start another thread on that subject....

>>> 2 - get the audio out of each instance separately, using send~ I  
>>> would guess. In this case I'd have to use #0 to name all the  
>>> send~s, and get those names out of each instance to name the  
>>> receive~ objects.
>>
>>
>> using send~/receive~ to communicate between inside/ouside of a  
>> poly~ is a really bad idea because
>
> Ah yes - I knew there was a reason I wasn't sure about this. I tried  
> this several years back and had all kinds of problems.
>
> > I would recommend using multiple out~ and something like gate~ to  
> route the signal to the appropriate outlet.

I have done this in the past and found it to be very CPU-demanding and  
inefficient. When you add one out ~ for each instacne, and end up  
using 9 voices, it means that for each instance, poly~ will be summing  
the output from each outlet, in effect requiring 9x9=81 additions  
happening at audio rate. I would consider making 9 instances of an  
abstraction instead. It might be more work to patch, but it will free  
up dps capacity for other tasks.

>
> Hmm. Ok, i can see that working, though that's a lot of out~s!  What  
> I need here is a funnel for audio signals, so that I can prefix each  
> audiostream with an identifier and then extract it outside the poly~.
>
> Isn't  there something like that  in tap.tools? Or is it in Jamoma  
> at the moment, and not yet included in tap.tools?

Yes, there are jcom.multi.in~ and jcom.multi.out~ abstractions in  
Jamoma, but they do unfortunately not work with poly~. In general I  
would say that support for multichannel signals in Max would be one of  
my top priority whishes for a long overdue new version of MSP. Maybe I  
should start another thread on that subject....

I struggled with this issue as well - I needed to link 3 seperate poly~ objects, each with 32 instances... and each instance needed to match between the three. I ended up going with a bunch of thispatcher -> sprintf set poly1send%i -> send~ and receive 'pairs'

It seems to work pretty well, the only issue I've noticed is some very strange latency going on, but for my purposes it's not enough to really bother me. I was toying with having gates or the like but I really didn't like the idea of wiring 256 gates (total - 64 out on the first, 64 in and 64 out on the second, and 64 in on the third)!

I would love some method of linking poly~'s like this a little more simply/cleaner. (This method was required, I had some objects that wouldn't run parallel)

My other line of thinking, which I never got very far on (I'm out of practice with jitter) was encoding all 64 of my audio streams into a jitter matrix (64 plane float? I wasn't sure what rate jitter ran at, I assumed there'd be slowdown), and transferring the audio around like that.

I struggled with this issue as well - I needed to link 3 seperate poly~ objects, each with 32 instances... and each instance needed to match between the three.  I ended up going with a bunch of thispatcher -> sprintf set poly1send%i -> send~ and receive 'pairs'

I would love some method of linking poly~'s like this a little more simply/cleaner.  (This method was required, I had some objects that wouldn't run parallel)

My other line of thinking, which I never got very far on (I'm out of practice with jitter) was encoding all 64 of my audio streams into a jitter matrix (64 plane float?  I wasn't sure what rate jitter ran at, I assumed there'd be slowdown), and transferring the audio around like that.


What I also did is to use matrix~ to route the sound from inside each poly~ voice.

What I also did is to use matrix~ to route the sound from inside each poly~ voice.
J-F.


you can also multiplex your signals, the drawback is you need to reconstruct the audio chain when you change it.

> Honestly, if this latency is the only problem, I'm not worried about 

Well, back when I was using send~/receive~ inside poly~s, I was 

getting audio signals showing up in places in my patch where it 

shouldn't be. Specifically, when I faded out those particular modules, 

the sound was still appearing at the instrument's output.

On 18 Feb 2009, at 17:11, mushoo wrote:
>>
>
> Honestly, if this latency is the only problem, I'm not worried about  
> it that much.

Well, back when I was using send~/receive~ inside poly~s, I was  
getting audio signals showing up in places in my patch where it  
shouldn't be. Specifically, when I faded out those particular modules,  
the sound was still appearing at the instrument's output.

> I'd now like to record each voice to a separate sfplay~ (ie one 

> sfplay~ per voice). It seems to me that there are two options:

> 1 - put an sfrecord~ inside the poly~ so that there are 9 instances. I 

> wonder if they would tend to be starting way out of sync?

This may not be what you want, but you could always record into an sfrecord~ with 9 channels (or 18 if you need stereo). That's a heck of a file, but everything is there, so if you want to then use single channels of it, set the corresponding channel in the buffer~ that reads it (could have 9 buffer~s to access each, for example). In this case you'd use the out~ and not need a gate to direct things, or if you want additional control, look into matrix~. Should be no problem with sync in this case as it's one file/object.

Also you could just record~ into a buffer~ with 1 channel each (or two for stereo pairs) and have 9 of these total. This way you can have the buffer~ available for manipulation using waveform~ rather than as an actual file, and could write each buffer~ as you want to save them.

I don't know the processing ramifications of either of these setups, sfrecord~ versus record~, buffer~ versus disk access, etc. I would imagine it's not too big a deal but having 18 could be. Cutting the sample rate to 22050 would help and IMO still sounds good for most things.

> I'd now like to record each voice to a separate sfplay~ (ie one  
> sfplay~ per voice). It seems to me that there are two options:
>
> 1 - put an sfrecord~ inside the poly~ so that there are 9 instances. I  
> wonder if they would tend to be starting way out of sync?
>

I don't know the processing ramifications of either of these setups, sfrecord~ versus record~, buffer~ versus disk access, etc. I would imagine it's not too big a deal but having 18 could be. Cutting the sample rate to 22050 would help and IMO still sounds good for most things.


Thanks for the suggestions. The thing with multitrack recordings with sfrecord~ is that I like to edit in Cubase, so I then have to split the recording into separate files. I have done this before, and in fact it's the reason that I bought SampleManager, the only programme I could find that would quickly split multitrack files.

That works fine, but it's an extra step. So I recently built a 10 separate stereo sfrecord~ patch to record the output of one of my instruments, and that worked fine too. The sync seems ok in Cubase, and is anyway easy to adjust.

Recording to buffer~ - this new instrument is very much for long improvisations. I'd need to have 9 * 30 minute stereo buffers to be on the safe side. I haven't done the math, but that seems like a lot of memory!

I've implemented the gate~ version, which doesn't seem to have created too much cpu strain. I might have a go at the scripting idea when I have time, though as scripting is something I haven't really tried to figure out yet, that might take a little longer :-)

Thanks for the suggestions. The thing with multitrack recordings with sfrecord~ is that I like to edit in Cubase, so I then have to split the recording into separate files. I have done this before, and in fact it's the reason that I bought SampleManager, the only programme I could find that would quickly split multitrack files.
That works fine, but it's an extra step. So I recently built a 10 separate stereo sfrecord~ patch to record the output of one of my instruments, and that worked fine too. The sync seems ok in Cubase, and is anyway easy to adjust.

Reviving a semi-dead thread here, but aside from the massive amount of patching it would require, would there be any problems caused by having a poly~ with 96 (possibly a few more) ins/outs? My patch has 32 instances with three different signals per instance that need to be shunted along.

It's 3 poly~ objects, total - first one is 32 instances, 3 outs (so 96 using gate~), the second is 2 ins, 2 outs, 32 instances, which is 64 on either side, and the third takes the outputs from the second poly~, along with one of the outputs of the third poly~, so 96 ins.

I'm assuming it's going to cause problems?

Reviving a semi-dead thread here, but aside from the massive amount of patching it would require, would there be any problems caused by having a poly~ with 96 (possibly a few more) ins/outs?  My patch has 32 instances with three different signals per instance that need to be shunted along.  

I'm assuming it's going to cause problems?


Instead of using poly~ what about just building one instance as a stand alone patch including a mute~ object and then loading multiple instances into bpatchers in a main patch?

I didn't read the thread above but how i solve this is to make 16 outputs to my poly 'voice' patch preceded by a gate~ with 16 outputs, one for each audio output. The gate number is set on load by the voice number (from thispoly~). This routes each voice to its own outlet. Easy.

https://cycling74.com/forums/share-pack-externals-and-max-6

https://cycling74.com/forums/a-i-wish-this-existed-for-the-greater-good-of-patching-signals-object

but i think there's currently no solution for it to work inside a poly~

edit : jcom.pack≈ and jcom.unpack≈ seem to work even with a poly~ between them !

this has been discussed recently :
https://cycling74.com/forums/share-pack-externals-and-max-6
and another resurrected thread :
https://cycling74.com/forums/a-i-wish-this-existed-for-the-greater-good-of-patching-signals-object

edit : jcom.pack≈ and jcom.unpack≈ seem to work even with a poly~ between them !


you can also try poly.send~ and poly.receive~ from CNMAT

many hidden things there... though there seems to be no poly.receive~, instead poly.bus~

and when they say, in the poly.send~ maxhelp :

do they mean the position of the outlet ? that this outlet must absolutely be to the left of the poly.send~ object ?

no, it means that the poly subpatch must have a signal output and in the main patch you must connect that output to the poly.bus~ object. It doesn't matter about the position of the outlet

FWIW, jcom.unpack≈ will not work inside a poly~, at least as of 6.1.2.  I would love to see CNMAT (or anyone) develop something for multiple inputs (so you could use instances of a poly to process different signals) as well as outs.  poly.send~ /bus~ work fine.

I see this is an older thread, but I haven't found a more recent one...so, two quick questions, if you have a moment to spare:

1. Has anyone had success using the poly.bus~ / .send~ object with Max 7? I am having a rather odd issue* with it and wonder if it is still working for others. I am running Max 7.0.1 on OSX (10.9.5).

2. If not, any other similar externals or solutions you would recommend? I’ve gone the gate~ route before, and I can do it again, it just seems like something like the poly.bus~/.send externals would be a much more efficient solution.

*The issue: The only signal that the objects will send and receive is a phantom cycle~ signal that seems to come from within poly.send~ itself. (The same sound is sent no matter what sound source I hook up, or how I try to modify the signal. All the other windows are closed, I’ve used the startwindow message for good measure, and I am unable to scale the sound with a *~ or live.gain~ object.) I should note that it only sends this ‘phantom’ signal when I have connected a signal input of some sort.

1. Has anyone had success using the poly.bus~ / .send~ object with Max 7?  I am having a rather odd issue* with it and wonder if it is still working for others.  I am running Max 7.0.1 on OSX (10.9.5). 

2. If not, any other similar externals or solutions you would recommend? I’ve gone the gate~ route before, and I can do it again, it just seems like something like the poly.bus~/.send externals would be a much more efficient solution.  

*The issue: The only signal that the objects will send and receive is a phantom cycle~ signal that seems to come from within poly.send~ itself.  (The same sound is sent no matter what sound source I hook up, or how I try to modify the signal.  All the other windows are closed, I’ve used the startwindow message for good measure, and I am unable to scale the sound with a *~ or live.gain~ object.)  I should note that it only sends this ‘phantom’ signal when I have connected a signal input of some sort.

there is nothing wrong (efficiency wise) in using "7" - gate msp.

I would not use an external where a core object does the job.

Okay, sounds like gate~ is the way to go. Thanks!

Okay, sounds like gate~ is the way to go.  Thanks!


getting separate audio feeds out of multivoice poly~