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

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

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

> 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

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

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.

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

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.

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

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?

I have a 16 voice instrument that I would like to have 16 individual outputs(one for each voice). Any ideas?

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 !

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 ?

Just for the record,

\M