getting separate audio feeds out of multivoice poly~

Feb 17, 2009 at 6:25pm

getting separate audio feeds out of multivoice poly~

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,
would be much appreciated.

thanks

David

#42368
Feb 17, 2009 at 6:39pm

#151633
Feb 17, 2009 at 6:55pm

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?

David

#151634
Feb 17, 2009 at 7:06pm

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.

[ddg]
Darwin Grosse

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

#151635
Feb 17, 2009 at 9:34pm

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

> But what is wrong with 18 outlets?

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.

thanks

David

#151636
Feb 18, 2009 at 7:33am


>>> 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 9×9=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….

Best,
Trond

#151637
Feb 18, 2009 at 8:45am

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.

#151638
Feb 18, 2009 at 11:11am

#151639
Feb 18, 2009 at 1:29pm

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

#151640
Feb 18, 2009 at 1:56pm

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

– Pasted Max Patch, click to expand. –
#151641
Feb 18, 2009 at 5:11pm

#151642
Feb 18, 2009 at 7:16pm

#151643
Feb 18, 2009 at 8:08pm

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.

David

#151644
Feb 19, 2009 at 3:39am

> 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.

#151645
Feb 19, 2009 at 9:22am

hi seejay,

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

David

#151646
Feb 23, 2009 at 5:46pm

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?

#151647
Apr 29, 2009 at 12:00am

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?

#151648
Jun 7, 2012 at 3:52pm

-

#151649
Jun 7, 2012 at 4:42pm

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.

#151650
Jun 7, 2012 at 4:54pm

this has been discussed recently :
http://cycling74.com/forums/topic.php?id=39919
and another resurrected thread :

http://cycling74.com/forums/topic.php?id=39930

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 !

#151651
Jun 7, 2012 at 5:40pm

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

#151652
Jun 7, 2012 at 8:56pm

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

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

“< --this is necessary to ensure that poly.bus~ will be below poly.send~ in the dsp chain"

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

#151653
Jun 7, 2012 at 9:07pm

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

#151654
Jun 7, 2012 at 9:11pm

thanks !

#151655
Jun 6, 2013 at 9:41pm

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.

Just for the record,

\M

#251946

You must be logged in to reply to this topic.