chthonic

Let's say one had four buffers playing simultaneously and wanted to bounce them to a single buffer, how would one go about doing that? I played around for 20min with the poke~, index~ and uzi objects. Here's my failed attempt at bouncing only one buffer, perhaps you can spot my flaw.

Let's say one had four buffers playing simultaneously and wanted to bounce them to a single buffer, how would one go about doing that? I played around for 20min with the poke~,  index~ and uzi objects. Here's my failed attempt at bouncing only one buffer, perhaps you can spot my flaw.

creating-a-patch-that-bounces-audio-files

Do you mean taking what's currently playing in all 4 buffers and putting that into a new one? If so, can't you just use groove~ for all 4 (or however many you want), put the output signals all into a single pair of L / R gainfaders, then into a record~ for a new buffer?

It would be nice for some more copy/paste/merge options like one has in audio editors, but that'll have to be built I guess. For bouncing, though, you can readily take any signal (or combination of signals) and record any length of these into a new buffer~.

I guess for non-real time bouncing the easiest thing would be to use an

Automatically save the buffers as sound-files (maybe with some generic name

into a temp folder), then send csound the name of these sound-files and have

an instrument with four players that bounces them into one file (with a

render to disk command). It would be quicker than playing through everything

> Do you mean taking what's currently playing in all 4 buffers and putting

> that into a new one? If so, can't you just use groove~ for all 4 (or however

> many you want), put the output signals all into a single pair of L / R

> gainfaders, then into a record~ for a new buffer?

> It would be nice for some more copy/paste/merge options like one has in

> audio editors, but that'll have to be built I guess. For bouncing, though,

> you can readily take any signal (or combination of signals) and record any

I guess for non-real time bouncing the easiest thing would be to use an
external like csound~:
Automatically save the buffers as sound-files (maybe with some generic name
into a temp folder), then send csound the name of these sound-files and have
an instrument with four players that bounces them into one file (with a
render to disk command). It would be quicker than playing through everything
in real-time in max/msp.
Peiman

On 05/07/07, Seejay James  wrote:
>
>
> Do you mean taking what's currently playing in all 4 buffers and putting
> that into a new one? If so, can't you just use groove~ for all 4 (or however
> many you want), put the output signals all into a single pair of L / R
> gainfaders, then into a record~ for a new buffer?
>
> Unless I'm misunderstanding...
>
> It would be nice for some more copy/paste/merge options like one has in
> audio editors, but that'll have to be built I guess. For bouncing, though,
> you can readily take any signal (or combination of signals) and record any
> length of these into a new buffer~.
>
> --CJ
>
>

Quote: seejayjames wrote on Thu, 05 July 2007 04:54

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

> Do you mean taking what's currently playing in all 4 buffers and putting that into a new one? If so, can't you just use groove~ for all 4 (or however many you want), put the output signals all into a single pair of L / R gainfaders, then into a record~ for a new buffer?

well he can mix the 4 buffers to a fifth by connecting their outputs to any other MSP object ... the bigger problem to copy between buffers in general + without third party externals.

i sometimes wish it would be easier then it curretly is.

the only solution i have used so far is doing it in realtime 

play~ and record~. of course thats not neccessarily sample exact ;)

Quote: seejayjames wrote on Thu, 05 July 2007 04:54
----------------------------------------------------
> Do you mean taking what's currently playing in all 4 buffers and putting that into a new one? If so, can't you just use groove~ for all 4 (or however many you want), put the output signals all into a single pair of L / R gainfaders, then into a record~ for a new buffer?
>
> Unless I'm misunderstanding...

well he can mix the 4 buffers to a fifth by connecting their outputs to any other MSP object ... the bigger problem to copy between buffers in general + without third party externals.
i sometimes wish it would be easier then it curretly is.

the only solution i have used so far is doing it in realtime 
play~ and record~. of course thats not neccessarily sample exact ;)


I would have thought you could do it using peek~ and poke~ and adding 

the numbers. I suppose the issues with that would be that you'd have 

to "compress" the number stream, perhaps by using scale, and then 

maybe normalise the buffer~once the transfer is done. I suppose 

another issue, depending on how busy the patch is, might be keeping 

Here's a single buffer copier based on something that someone else 

posted (thanks, whoever you were!). This shows one way of using peek~ 

to copy buffers, and should be modifiable.

I would have thought you could do it using peek~ and poke~ and adding  
the numbers. I suppose the issues with that would be that you'd have  
to "compress" the number stream, perhaps by using scale, and then  
maybe normalise the buffer~once the transfer is done. I suppose  
another issue, depending on how busy the patch is, might be keeping  
the 4 number streams in sync.
Here's a single buffer copier based on something that someone else  
posted (thanks, whoever you were!). This shows one way of using peek~  
to copy buffers, and should be modifiable.

> Let's say one had four buffers playing simultaneously and wanted to

> bounce them to a single buffer, how would one go about doing that? I

> played around for 20min with the poke~, index~ and uzi objects.

> Here's my failed attempt at bouncing only one buffer, perhaps you can

Just take your four groove~s, play them and record~ them mixed into a 

fifth buffer~, after you've done that you can bounce it back, or simply 

Out of the audio domain its also possible with peek~:

Nicholas Esterer schrieb:
> Let's say one had four buffers playing simultaneously and wanted to
> bounce them to a single buffer, how would one go about doing that? I
> played around for 20min with the poke~,  index~ and uzi objects.
> Here's my failed attempt at bouncing only one buffer, perhaps you can
> spot my flaw.

Just take your four groove~s, play them and record~ them mixed into a 
fifth buffer~, after you've done that you can bounce it back, or simply 
assign it...

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

Here's another take on a patch that bounces audio files:

Would faster-than-realtime bouncing to a buffer be useful in MaxMSP, as opposed to the realtime bouncing that has been discussed above? The faster-than-realtime bouncing capability of some commercial mixing programs seems vastly superior to the realtime-only bouncing limitation of certain other mixing programs, where your hour long mix takes an hour to bounce down even if you only wanted to tweak a few seconds of it.

But how useful would faster-than-realtime bouncing be in the MaxMSP world? I'm not suggesting it wouldn't be useful, just curious what people think.

i'm looking to bounce the samples contained in the buffers almost instantaneously, without waiting for them to play through in real time

My plan is to create a patch that manipulates samples and allows one to cut bits of many samples and combine them into a single hybrid. To ease the process of manipulating these new hybrids, it would be simpler to bounce them to new files, and manipulate these files from scratch.

I just added overdub capabilities to my buffet~ object, which should do everything you described. I've attached a copy in case you'd like to try it.

> My plan is to create a patch that manipulates samples and allows one to cut bits of many samples and combine them into a single hybrid. To ease the process of manipulating these new hybrids, it would be simpler to bounce them to new files, and manipulate these files from scratch.

----------------------------------------------------
> My plan is to create a patch that manipulates samples and allows one to cut bits of many samples and combine them into a single hybrid. To ease the process of manipulating these new hybrids, it would be simpler to bounce them to new files, and manipulate these files from scratch.
----------------------------------------------------


Am 08.07.2007 um 18:15 schrieb Eric Lyon:

> I just added overdub capabilities to my buffet~ object, which should 

> do everything you described. I've attached a copy in case you'd like 

btw the setbuf message is also very useful but heavily underdocumented 

> I just added overdub capabilities to my buffet~ object, which should 
> do everything you described. I've attached a copy in case you'd like 
> to try it.

Lovely addition to el.buffet~!
btw the setbuf message is also very useful but heavily underdocumented 
;)

Thanks! I should document "setbuf" one of these days. I view it as a convenience message, and generally recommend using a separate buffet~ object for each buffer~ you want to alter. If you're hooked on "setbuf" (and I've found some good uses of it myself) just be sure not to use it to switch buffers during a buffet~ operation or you could shortly be restarting Max ;)

> Am 08.07.2007 um 18:15 schrieb Eric Lyon:

> > I just added overdub capabilities to my buffet~ object, which should 

> > do everything you described. I've attached a copy in case you'd like 

> btw the setbuf message is also very useful but heavily underdocumented 

----------------------------------------------------
>
> Am 08.07.2007 um 18:15 schrieb Eric Lyon:
>
> > I just added overdub capabilities to my buffet~ object, which should 
> > do everything you described. I've attached a copy in case you'd like 
> > to try it.
>
> Lovely addition to el.buffet~!
> btw the setbuf message is also very useful but heavily underdocumented 
> ;)
>
> cheers, g.
>
>
----------------------------------------------------


That is sort of what I am trying to do, but faster than real-time. We start with 4 buffers and overdub them into 1 in some amount of processing time that is much less than the time it would take to play them. I don't think MSP allows for that kind of thing, because it runs at the sampling rate of your sound card. If you think otherwise, I am open to suggestions. I am also wondering if one can do the same sort of thing with ffts, for example converting audio files to Cartesian Coordinate pairs, faster than real time.

> That is sort of what I am trying to do, but faster than real-time.

Are you answering to a thread from last year? Please at least quote

something.... Or better create a new one after more than half a year...

> We start with 4 buffers and overdub them into 1 in some amount of 

> processing time that is much less than the time it would take to play

> them. I don't think MSP allows for that kind of thing, because it 

> runs at the sampling rate of your sound card.

It does allow for it, that's what the non-realtime driver is for. To get 

scheduler timing correct, you need to check scheduler in audio-interrupt 

But beware, if you bounce to sfrecord~ or read with sfplay~, you'll end 

up being slower than realtime. This is a syncread problem or somthing I 

never understood but a filesystem thingy. If you load and bounce into 

buffer~s, you'll be faster (if your memory is big enough to hold all 

Nicholas Esterer schrieb:
> That is sort of what I am trying to do, but faster than real-time.

Are you answering to a thread from last year? Please at least quote
something.... Or better create a new one after more than half a year...

> We start with 4 buffers and overdub them into 1 in some amount of 
> processing time that is much less than the time it would take to play
> them. I don't think MSP allows for that kind of thing, because it 
> runs at the sampling rate of your sound card. 

It does allow for it, that's what the non-realtime driver is for. To get 
scheduler timing correct, you need to check scheduler in audio-interrupt 
though...

But beware, if you bounce to sfrecord~ or read with sfplay~, you'll end 
up being slower than realtime. This is a syncread problem or somthing I 
never understood but a filesystem thingy. If you load and bounce into 
buffer~s, you'll be faster (if your memory is big enough to hold all 
data...)

Creating a Patch That Bounces Audio Files