Chewwie

What's the best approach to overdubbing/resampling in Max5?

I have run many searches on the forum to find ananswer to this question and have found a number of topics which provide solutions - however I have not succeeded in making any solution work very well.

I am new to Max and am trying to make a simple drum pad using a keyboard/dancemat. When a key is triggered it plays a sample and what I want to be able to do is record and overdub these samples so a user can build up and layer a complex beat - whilst keeping perfect syncronization.

I have a working version which uses the Fripp~ object but this seems to subtly full out of sync which over a minute or so is very obvious and not at all useful. I have also played with xsample~ but not had much luck with that either. I read somewhere that PeRcolate's frecord~ does exactly what I want but I can only find it for a Mac and I'm on a PC. Does anyone have this for PC?

All the topics on this forum relating to overdubbing seem quite dated and so I just thought it might be worth asking this question to see if I have missed something somewhere and there is an easy way to achieve this with Max 5 - or if there is a new object around which people are using?

If you have any suggestions or could share a patch which will help me it will be much appreciated. I have a presentation (at college) in a few days and this syncing issue is really the last thing I need to fix.

whats-the-best-approach-to-overdubbingresampling

Using count~ and index~ is the tightest way of doing this type of thing. You could do it with play~ or groove~ as well, but index~ will give you the best audio quality in this situation. I've not used percolate's recordf~, but as I understand it's just record~ with a feedback loop, you could achieve essentially the same thing using the loop mode of record~, and using send~/receive~ to create a feedback loop, although this method would mean that each consecutive overdub would be one signal vector length of samples behind the existing audio........maybe fripp~ uses a similar method hence the drifting out of time?

This patch has solid timing (it's basically the same as the endless resampling patch posted by Andrew Benson, maybe you've seen it already and it's not what you need). All it is is a circular buffer delay with a feedback amplitude of 1 so that it has no decay.

If this isn't quite what you need help with, I'm sure you could modify the patch to do what you want, or post another question, maybe with your fripp~ patch to show what you mean.

Using count~ and index~ is the tightest way of doing this type of thing.  You could do it with play~ or groove~ as well, but index~ will give you the best audio quality in this situation.  I've not used percolate's recordf~, but as I understand it's just record~ with a feedback loop, you could achieve essentially the same thing using the loop mode of record~, and using send~/receive~ to create a feedback loop, although this method would mean that each consecutive overdub would be one signal vector length of samples behind the existing audio........maybe fripp~ uses a similar method hence the drifting out of time?

This patch has solid timing (it's basically the same as the endless resampling patch posted by Andrew Benson, maybe you've seen it already and it's not what you need).  All it is is a circular buffer delay with a feedback amplitude of 1 so that it has no decay.  

If this isn't quite what you need help with, I'm sure you could modify the patch to do what you want, or post another question, maybe with your fripp~ patch to show what you mean.


timloyd - that is great - thanks! It's exactly what I have been looking for and it looks so simple compared to some other solutions.

Just one question regarding the patch - how do I go about switching to 'just playback' and no recording - so a user can test out a beat before laying it down. At the moment i can toggle it to record on/off but is it easy to add a toggle for just playback?

Does anyone have any idea of how to add a playback (no record) feature to the patch timloyd shared? I am not familiar with the index/count method; I've been playing with adding this feature but am not sure how to do it. I think it is probably very simple to experienced users - but this is always the case when you know how to use a program.

Any help would be great - deadline looming :S

You could simply add a second [toggle]->[sig~] connected to the [count~ 0 1] object, as a play button.

While this toggle is on, the record toggle will function as punch in/out.

You could simply add a second [toggle]->[sig~] connected to the [count~ 0 1] object, as a play button.
While this toggle is on, the record toggle will function as punch in/out.


...and he's getting some credit when you turn in your homework project, I assume....

Of course. However we are not marked on the code/software annoyingly - its purely on the finished sound output.

If sound quality is important, then you may prefer using 

 as the latest object produces ugly artifacts when played at speeds different from 1.

 needs to be driven by a 0-1 phasor. You can get both positions, i.e. sample position and 0-1 position, using something like this:

If sound quality is important, then you may prefer using wave~ rather than index~ as the latest object produces ugly artifacts when played at speeds different from 1.

unfortunately, wave~ needs to be driven by a 0-1 phasor. You can get both positions, i.e. sample position and 0-1 position, using something like this:


You're right that index~ will alias with variable playback speeds, but wave~ would be my last choice to replace it with! As I understand it has the worst interpolation of all the playback objects, because it's designed as a wavetable rather than for longer sample playback.

Also, using phasor~, trunc~ and poke~ together is likely to create aliasing while recording, because the combination of roundoff error and truncation results in a signal with an unstable delta between increments. It won't be consistently incrementing by one sample, which for poke~ is basically the same thing that causes aliasing in index~ with playback speeds not equal to 1.

The best alternative would be to still use the count~ poke~ part for recording, but to use phasor~ and play~ for playback, although then there is the need to synchronize them, especially when you DO want normal speed playback. This would be tricky because phasor~ can't be reset to 0 phase at signal rate.......there is probably a way of doing it though, there's part of an oscillator hard sync example patch that would help with this if I remember correctly.

Although, the notion of having variable speed playback in a circular buffer overdubbing system might not be suitable in the context of recording rhythmic loops and stacking them on top of each other. It could create some pretty cool sounds though!

In the context of Chewwie's project, I think variable speed playback would be better realized using separate buffers for each consecutive overdub, sticking to the count~>poke~ recording method, and using phasor~ and play~ for playback. Rate~ could be used to adjust the speed of each loop........can't think exactly how to make that patch off the top of my head, but it's not going to be really complex.

You're right that index~ will alias with variable playback speeds, but wave~ would be my last choice to replace it with!  As I understand it has the worst interpolation of all the playback objects, because it's designed as a wavetable rather than for longer sample playback.

Also, using phasor~, trunc~ and poke~ together is likely to create aliasing while recording, because the combination of roundoff error and truncation results in a signal with an unstable delta between increments.  It won't be consistently incrementing by one sample, which for poke~ is basically the same thing that causes aliasing in index~ with playback speeds not equal to 1.

The best alternative would be to still use the count~ poke~ part for recording, but to use phasor~ and play~ for playback, although then there is the need to synchronize them, especially when you DO want normal speed playback.  This would be tricky because phasor~ can't be reset to 0 phase at signal rate.......there is probably a way of doing it though, there's part of an oscillator hard sync example patch that would help with this if I remember correctly.

Although, the notion of having variable speed playback in a circular buffer overdubbing system might not be suitable in the context of recording rhythmic loops and stacking them on top of each other.  It could create some pretty cool sounds though!

In the context of Chewwie's  project, I think variable speed playback would be better realized using separate buffers for each consecutive overdub, sticking to the count~>poke~ recording method, and using phasor~ and play~ for playback.  Rate~ could be used to adjust the speed of each loop........can't think exactly how to make that patch off the top of my head, but it's not going to be really complex.


My bad, I just noticed the [+~ 0.5 ] in your patch that sorts out the problem with phasor~ and trunc~. Very useful to know!

My bad, I just noticed the [+~ 0.5 ] in your patch that sorts out the problem with phasor~ and trunc~.  Very useful to know!


Thanks for your comments. I'm actually working on such a loop project...

. If you insert it in your patch, the delta will be 1, as with 

 gave me good results so far, without aliasing, but 

 was really unusable. I need to do more tests anyway, on longer buffers.

in the patch I sent, there is a +~ 0.5. If you insert it in your patch, the delta will be 1, as with count~.

About interpolation, wave~ gave me good results so far, without aliasing, but index~ was really unusable. I need to do more tests anyway, on longer buffers.


I know it's an old post but could anyone explain what the patches actually do? 

( i'd like to learn something rather than having me simply paste them in my project?!)

I know it's an old post but could anyone explain what the patches actually do? 
( i'd like to learn something rather than having me simply paste them in my project?!)


(so they go by appearances only? must be an american institution, ZING! 😜)

we are not marked on the code/software annoyingly - its purely on the finished sound output

(so they go by appearances only? must be an american institution, ZING! 😜) 

What's the best approach to overdubbing/resampling?