Forums > MaxMSP

overdub function


max
August 21, 2006 | 11:36 am

hi everybody,
i would create a record object with overdub capabilities…i don’t understand the Xrecord object…i think about a system which ,when you active overdub ,make a looping record and stack on the buffer like overdub on a looper pedal….without time limits
I’m a beginner in max : i’m lost!!!!
could anybody help me????
thanks a lot by advance


August 21, 2006 | 3:15 pm

im no max expert, but, id consider using 2 buffers, one is used just for the overdub recording. you could possibly switch back and forth between the 2 buffers after each recording. or, maybe use 2 buffers, and only ever playback from one of them, using the other just while recording (it plays backt he buffer output to overdub over). to do this, youd have to copy the contents of buffer A to buffer B after you are done overdubbing.

im sure someone else here has a much more elegant solution…


August 21, 2006 | 4:30 pm

I was opening one of my older patches in MaxMSP 4.6 on my macbook.

MaxMSP is crashing when sending a bang or a 1 to the pict object. The
pict help patch has the same behaviour.

best,

Edwin

On 21-aug-2006, at 17:15, kid_sputnik wrote:

>
> im no max expert, but, id consider using 2 buffers, one is used
> just for the overdub recording. you could possibly switch back and
> forth between the 2 buffers after each recording. or, maybe use 2
> buffers, and only ever playback from one of them, using the other
> just while recording (it plays backt he buffer output to overdub
> over). to do this, youd have to copy the contents of buffer A to
> buffer B after you are done overdubbing.
>
> im sure someone else here has a much more elegant solution…
> –
> daniel b


August 21, 2006 | 5:26 pm

Thanks, I can reproduce and have fixed the problem for the next release.

jb

Am 21.08.2006 um 18:30 schrieb Edwin van der Heide:

> I was opening one of my older patches in MaxMSP 4.6 on my macbook.
>
> MaxMSP is crashing when sending a bang or a 1 to the pict object.
> The pict help patch has the same behaviour.
>
> best,
>
> Edwin


August 26, 2006 | 10:57 am

kid_sputnik wrote:
> im sure someone else here has a much more elegant solution…

One buffer is fine, there is no problem to play from and record into a
buffer~ at the same time…
To overdub, just rerecord what you play (vulgo feedback, but keep the
record position at least one sample behind the play position… ;-)

It also depends what you consider "overdub". In the old sense, you would
mix a played back track of a multitrack tape together with the new
material to a new track (that would correspond to the suggestion of two
buffers…). With the arrival of multitrack machines of 24 to 96 tracks
this technique wasn’t important anymore…
Some hardware loopers allow just to record on severeal tracks, and when
you mix them you get a similar result, but you could play them still
individually. With real overdub you would loose the original versions
with each overdub, you’d have to live with the mix…

Stefan


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


August 26, 2006 | 5:41 pm


August 26, 2006 | 8:55 pm

Stefan Tiedje wrote:

> One buffer is fine, there is no problem to play from and record into a
> buffer~ at the same time…
> To overdub, just rerecord what you play (vulgo feedback, but keep the
> record position at least one sample behind the play position… ;-)
>

yah, i was thinking of mentioning this, but i wasnt sure if it was feasable, because of the way MSP works with audio vector sizes > 1 (i come from NI Reaktor; the R5 core engine works with a vector size of 1 so its easy to work with 1-sample offsets, wasnt sure about MSP).


August 27, 2006 | 3:25 pm

Patrick Delges wrote:
> Last time I tried, there were problems when the play and record
> positions crossed, which may happen if you play backward, or at the
> different speed, than the one you use for recording. There was a
> discussion about this topic a long time ago…
> Maybe it changed since that time, but I can understand that it’s not
> easy to know what vector in the buffer you’re supposed to play while
> it’s being modified.

In this case it has nothing to do with vectors, just think of a play
head and a record head on a long loop. If you play just before the
record head, the signal you hear is delayed by (almost) the loop length.
If you move across and play behind the record head, you play whats just
recorded, the delay would be (almost) zero… just logic. You can’t look
into the future, even not in Max…
At the point where you cross, it will most likely click, as the two
signals are not related to each other, ju jump from the past to now…

Stefan


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


August 27, 2006 | 4:15 pm


Viewing 9 posts - 1 through 9 (of 9 total)