UnUnUnium

Hello everyone! I'm building an audio 'pool' to feed an automated matrix patch I've been working on, and I need some help.

What I'm trying to acheive is this: I need to have 64 different play~ objects looping audio from the same long buffer, each looping a subsequent section of audio from it. In other words, Play~ object 1 would loop 1-1000ms, play~ object 2 would loop 1001-2000ms, etc, until the last play~ object plays the last section of audio. The play objects would be constantly looping, each representing a section of the buffer which could be recorded into at will.

I am left scratching my head on how to acomplish the calculations necessary to produce those playback times (based on an arbitrary record length), as well as how to effectively loop the objects at the specific lengths I require.

I'd love to hear any suggestions as to get started on this- I am open to using objects other than play~, by the way, I only started with play~ because it seemed to have a smaller CPU cost, a necessary consideration considering I do need 64 of them!

What I'm trying to acheive is this: I need to have 64 different play~ objects looping audio from the same long buffer, each looping a subsequent section of audio from it. In other words, Play~ object 1 would loop 1-1000ms, play~ object 2 would loop 1001-2000ms, etc, until the last play~ object plays the last section of audio. The play objects would be constantly looping, each representing a section of the buffer which could be recorded into at will. 

looping-buffer-play-bank-suggestions

Here's one way to do it. I used groove~ because it's easy to give it beginning and end playback times. I did a little extra math to make it sample accurate. If you just did 1-1000ms and then 1001-2000ms, you'd miss 44 samples of the recording. This patch starts each section at the next sample. Hopefully this gets you on your way. I've only been using Max/Msp for a month, so there are probably simpler ways to accomplish what you're trying to do using objects I don't know about yet...I just wanted to see if I could figure it out for my own learning process...and maybe help you out as well. :) Sorry it's a bit messy, I wanted to loadbang everything so you could just fire it up... the [clocker] object and [p math] abstraction are the important parts....hope this helps!

Here's one way to do it.  I used groove~ because it's easy to give it beginning and end playback times.  I did a little extra math to make it sample accurate.  If you just did 1-1000ms and then 1001-2000ms, you'd miss 44 samples of the recording.  This patch starts each section at the next sample.  Hopefully this gets you on your way.  I've only been using Max/Msp for a month, so there are probably simpler ways to accomplish what you're trying to do using objects I don't know about yet...I just wanted to see if I could figure it out for my own learning process...and maybe help you out as well.  :)  Sorry it's a bit messy, I wanted to loadbang everything so you could just fire it up... the [clocker] object and [p math] abstraction are the important parts....hope this helps!

Note: Each [p math] has some different multipliers, so make sure you check out each one to see the pattern you would have to use....

Note:  Each [p math] has some different multipliers, so make sure you check out each one to see the pattern you would have to use....


[poly~] is your friend for this kind of stuff.

here is an example with a sound file, you might want to change it for live recorded files.

you 64 instances of the same player. the soundfile is divide in 64 chunks each instance plays a given chunk. volume can be adjusted for each player.

accomodate the patch for your needs, many other things can be done with [poly~]. the world of clones is a nice little labyrinth worth walking into ;)

Quote: UnUnUnium wrote on Sun, 07 January 2007 16:26

----------------------------------------------------

> Hello everyone! I'm building an audio 'pool' to feed an automated matrix patch I've been working on, and I need some help.

> What I'm trying to acheive is this: I need to have 64 different play~ objects looping audio from the same long buffer, each looping a subsequent section of audio from it. In other words, Play~ object 1 would loop 1-1000ms, play~ object 2 would loop 1001-2000ms, etc, until the last play~ object plays the last section of audio. The play objects would be constantly looping, each representing a section of the buffer which could be recorded into at will. 

[poly~] is your friend for this kind of stuff.
here is an example with a sound file, you might want to change it for live recorded files.
you 64 instances of the same player. the soundfile is divide in 64 chunks each instance plays a given chunk. volume can be adjusted for each player.
accomodate the patch for your needs, many other things can be done with [poly~]. the world of clones is a nice little labyrinth worth walking into ;)

Quote: UnUnUnium wrote on Sun, 07 January 2007 16:26
----------------------------------------------------
>  Hello everyone! I'm building an audio 'pool' to feed an automated matrix patch I've been working on, and I need some help.
>
> What I'm trying to acheive is this: I need to have 64 different play~ objects looping audio from the same long buffer, each looping a subsequent section of audio from it. In other words, Play~ object 1 would loop 1-1000ms, play~ object 2 would loop 1001-2000ms, etc, until the last play~ object plays the last section of audio. The play objects would be constantly looping, each representing a section of the buffer which could be recorded into at will. 
>

Cool that's kind of like the grm freeze plugin!

On 8 Jan 2007, at 06:21, karl-otto von oertzen wrote:

Peiman
On 8 Jan 2007, at 06:21, karl-otto von oertzen wrote:

Quote: peimankhosravi@gmail.com wrote on Sun, 07 January 2007 23:04

> Cool that's kind of like the grm freeze plugin!

hum... i think i ll have to work a little harder until i make something that sounds like some GRM Tool ;)

but you could easily implement some pitch variations for each voice, and also change each voice's length to get closer to the grm freeze plugin

Quote: peimankhosravi@gmail.com wrote on Sun, 07 January 2007 23:04
----------------------------------------------------
> Cool that's kind of like the grm freeze plugin!
>

but you could easily implement some pitch variations for each voice, and also change each voice's length to get closer to the grm freeze plugin


If you're into the whole live recording side of things, you should stutter~ object... This object can have a lot of internal playback buffers~ / players.

Dunno if it does what you wan't, but stutter is surely among my fav objects for realtime looping.

First off thank you all very much for your replies- there is some very helpful stuff I'm finding, plenty of "now I get it" moments.

The only problem with the poly~ solution is that I need all 64 outputs to be playing constantly, as inefficient as that is- the reason being that it is feeding a 64 input matrix which switches with a variable ramp time- I might be missing the point though. This, however, is incredibly helpful as I've been trying to wrap my head arouns poly~ for another project I'm working on- your patch will be very useful to that end.

Temporalist, your solution is pretty close to what I need-I actually don't need complete sample accuracy, at least in this part of the patch, but I'd love to know- how did you figure out the whole "44 samples missing" thing? That's be great to know for future reference.

I do plan on checking out the stutter~ object in the near future- that is another one I need to get my head around- real-time sampling and looping are what I'm interested in doing, so I should get cozy with stutter~...

Right now I am using hr.wave~ for playback, and I'm feeling the sound quality improvement (over the original wave~) is very noticable....

Thanks again everyone for all your help, this all makes for quite a good launching pad for my project!

Thanks again everyone for all your help, this all makes for quite a good launching pad for my project!
   Cheers, Jeremy


> The only problem with the poly~ solution is that I need all 64 outputs to be playing constantly, as inefficient as that is- the reason being that it is feeding a 64 input matrix which switches with a variable ramp time- I might be missing the point though. This, however, is incredibly helpful as I've been trying to wrap my head arouns poly~ for another project I'm working on- your patch will be very useful to that end.

can u send a patch of what you are trying to do, because with the [poly~] solution all 64 players are playing constantly. in my example they just have all the same length, which could be easily changed.

i am not sure i entirely understand what you are trying to do :

- you want 64 players playing from the same ( long) buffer~

- you want each player to play a chunk of the buffer~

- the content of the buffer is changing as you are recording live input into it

- you want to be able to change the lenght of each chunk dynamically but have no overlap timewise between the players, meaning loopout point of player A does not overlap with loopin point pf player B ... ?

> The only problem with the poly~ solution is that I need all 64 outputs to be playing constantly, as inefficient as that is- the reason being that it is feeding a 64 input matrix which switches with a variable ramp time- I might be missing the point though. This, however, is incredibly helpful as I've been trying to wrap my head arouns poly~ for another project I'm working on- your patch will be very useful to that end.
>

can u send a patch of what you are trying to do, because with the [poly~] solution all 64 players are playing constantly. in my example they just have all the same length, which could be easily changed.
i am not sure i entirely understand what you are trying to do :
tell me if i am correct or not :
- you want 64 players playing from the same ( long) buffer~
- you want each player to play a chunk of the buffer~
- the content of the buffer is changing as you are recording live input into it
- you want to be able to change the lenght of each chunk dynamically but have no overlap timewise between the players, meaning loopout point of player A does not overlap with loopin point pf player B ... ?
i might b missing something ;)
best,
ko


So the one thing I need that the poly~ solution doesn't provide is multiple simultaneous outputs- meaning, 64 outputs all playing at once, connected to 64 inputs of a matrix object. Make sense? The poly~ provide 64 possible simultaneous voices, but NOT 64 simultaneously available outputs. Or did I miss something in the patch? i saw it having two outputs.

I could post a patch, but it's got many abstractions and might be overkill- but let me know if you still need them after my explanation, and I'll post them.

  So the one thing I need that the poly~ solution doesn't provide is multiple simultaneous outputs- meaning, 64 outputs all playing at once, connected to 64 inputs of a matrix object. Make sense? The poly~ provide 64 possible simultaneous voices, but NOT 64 simultaneously available outputs. Or did I miss something in the patch? i saw it having two outputs.

  I could post a patch, but it's got many abstractions and might be overkill- but let me know if you still need them after my explanation, and I'll post them.

do you need the 64 outputs to further process them individually ( route them to various effects for instance ) or to route them through different outputs of a multichannelled sound card ?

in my example you can change the volume of each player via the [multislider].

you could add more outputs to the [poly~] ( i cant remember if there are any limitations, i assume there are, specially CPU wise, more outputs on 64 instances of an abstraction nested in a [poly~] will start taxing your machine ;) ).

maybe you can just use an abstraction repeated 64 times.

there might b a more elegant way to do it though :)

Quote: UnUnUnium wrote on Mon, 08 January 2007 14:34

> So the one thing I need that the poly~ solution doesn't provide is multiple simultaneous outputs- meaning, 64 outputs all playing at once, connected to 64 inputs of a matrix object. Make sense? The poly~ provide 64 possible simultaneous voices, but NOT 64 simultaneously available outputs. Or did I miss something in the patch? i saw it having two outputs.

> I could post a patch, but it's got many abstractions and might be overkill- but let me know if you still need them after my explanation, and I'll post them.

i see, sorry for my slow understanding.
do you need the 64 outputs to further process them individually ( route them to various effects for instance ) or to route them through different outputs of a multichannelled sound card ?
.
in my example you can change the volume of each player via the [multislider].
you could add more outputs to the [poly~] ( i cant remember if there are any limitations, i assume there are, specially CPU wise, more outputs on 64 instances of an abstraction nested in a [poly~] will start taxing your machine ;) ).

maybe you can just use an abstraction repeated 64 times.
there might b a more elegant way to do it though :)

Quote: UnUnUnium wrote on Mon, 08 January 2007 14:34
----------------------------------------------------
> Hey Karrrlo,
>
>   So the one thing I need that the poly~ solution doesn't provide is multiple simultaneous outputs- meaning, 64 outputs all playing at once, connected to 64 inputs of a matrix object. Make sense? The poly~ provide 64 possible simultaneous voices, but NOT 64 simultaneously available outputs. Or did I miss something in the patch? i saw it having two outputs.
>
>   I could post a patch, but it's got many abstractions and might be overkill- but let me know if you still need them after my explanation, and I'll post them.
>
> cheers, J
----------------------------------------------------


First off, I'm not quite sure I understand how the send item in working in the abstraction you posted (I am quite a new MaxMSP user).

Is the Sprintf changing the suffix of the DummyL DummyR send~ objects depending on the voice number , which would then go to (for example) a DummyL1 DummyR1 receive~ object, which would be connected to output objects within the poly~ patcher? If so, would they have to be out~ objects, or standard outlets?

It's true that sequencing before the audio is probably a more efficient approach- I do wonder if it would have quite the same effect though, given the ability of the matrix to crossfade... I suppose a long decay could have the same effect. For now I have to go with what I've already set up because it is a class assignment due this friday!

First off, I'm not quite sure I understand how the send item in working in the abstraction you posted (I am quite a new MaxMSP user). 

> First off, I'm not quite sure I understand how the send item in working in the abstraction you posted (I am quite a new MaxMSP user). 

1st, dont' mess up bewteen send and send~. Send is for Max message, 

send~ is for signals. I assume it may be a typo, but who knows...

> Is the Sprintf changing the suffix of the DummyL DummyR send~ objects depending on the voice number , which would then go to (for example) a DummyL1 DummyR1 receive~ object, which would be connected to output objects within the poly~ patcher? If so, would they have to be out~ objects, or standard outlets?

The DummyL & R names are only here because send~ needs an initialisation 

argument. The sprintf is used here to 'build' (concatenate ?) the actual 

name of the targetted receive~. It will be whatever you want + the 

instance number as a suffix. Then, you only have to set a few receive~ 

objects outside the poly~, with the corresponding names. Let's say you 

choose 'Go_Out_L' & 'Go_Out_R', the sprintf will automatically 'set' the 

send~ objects to target the 'Go_Out_L1' & 'Go_Out_R1', then the 

'Go_Out_L2' and so on. So, may sure you have some [receive~ Go_Out_L1] & 

so on objects outside to catch the sound. It's only a way of dynamicaly 

> It's true that sequencing before the audio is probably a more efficient approach- I do wonder if it would have quite the same effect though, given the ability of the matrix to crossfade... I suppose a long decay could have the same effect. For now I have to go with what I've already set up because it is a class assignment due this friday!

It realy depends on what you're after. I like matrix~ very much but i 

always try to find another solution before using it because it always 

sucked a lot of cpu on my machines (when used intensively).

Jeremy Keenan wrote:
> Thank you for your reply f.e....
>
> First off, I'm not quite sure I understand how the send item in working in the abstraction you posted (I am quite a new MaxMSP user). 
>
1st, dont' mess up bewteen send and send~. Send is for Max message, 
send~ is for signals. I assume it may be a typo, but who knows...
>
> Is the Sprintf changing the suffix of the DummyL DummyR send~ objects depending on the voice number , which would then go to (for example) a DummyL1 DummyR1 receive~ object, which would be connected to output objects within the poly~ patcher? If so, would they have to be out~ objects, or standard outlets?
>
The DummyL & R names are only here because send~ needs an initialisation 
argument. The sprintf is used here to 'build' (concatenate ?) the actual 
name of the targetted receive~. It will be whatever you want + the 
instance number as a suffix. Then, you only have to set a few receive~ 
objects outside the poly~, with the corresponding names. Let's say you 
choose 'Go_Out_L' & 'Go_Out_R', the sprintf will automatically 'set' the 
send~ objects to target the 'Go_Out_L1' & 'Go_Out_R1', then the 
'Go_Out_L2' and so on. So, may sure you have some [receive~ Go_Out_L1] & 
so on objects outside to catch the sound. It's only a way of dynamicaly 
naming the targets.
> It's true that sequencing before the audio is probably a more efficient approach- I do wonder if it would have quite the same effect though, given the ability of the matrix to crossfade... I suppose a long decay could have the same effect. For now I have to go with what I've already set up because it is a class assignment due this friday!
>
It realy depends on what you're after. I like matrix~ very much but i 
always try to find another solution before using it because it always 
sucked a lot of cpu on my machines (when used intensively).
> Thanks again, Jeremy
>
you're welcome

> The outputs are going to be 'cut up' by the matrix~, because the

> matrix~ is controlled by a step sequencer that controls the routing

> as well as the ramp time....This is then re-recorded into 1 of 8

> different buffers, which are played back by hr.wave~ with pitch

> control, all synched to a common tempo.

But then you could put easily the 8 outputs into the poly~s and use a 

selector~ or matrix~ inside the poly~ to choose the output. You'd create 

the whole matrix with the poly~s, as you could also only trigger the 

This shows it is really essential to describe your original goal, not 

only asking for the solution for a step you believe is necesary for your 

goal. It might lead to much more efficient overall solutions...

Jeremy Keenan wrote:
> The outputs are going to be 'cut up' by the matrix~, because the
> matrix~ is controlled by a step sequencer that controls the routing
> as well as the ramp time....This is then re-recorded into 1 of 8
> different buffers, which are played back by hr.wave~ with pitch
> control, all synched to a common tempo.

But then you could put easily the 8 outputs into the poly~s and use a 
selector~ or matrix~ inside the poly~ to choose the output. You'd create 
the whole matrix with the poly~s, as you could also only trigger the 
poly~ if its supposed to sound...

This shows it is really essential to describe your original goal, not 
only asking for the solution for a step you believe is necesary for your 
goal. It might lead to much more efficient overall solutions...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


> I forgot this insane behavior of send/receive... This should be 

> stopped right now, it's against max's ethical.

On 11-Jan-2007, at 3:21, f.e wrote:
> I forgot this insane behavior of send/receive... This should be  
> stopped right now, it's against max's ethical.

Looping buffer "play~ bank" suggestions.