Rodrigo

I know this is trudging through very common waters, but I'm returning to max after many years away from it (I stopped using it before max5 came out), and am having a hard time figuring out how to build what it is I'm trying to build.

Essentially I'm trying to build a (simple) sample/playback patch that sets sample/loop length dynamically(asynchronously), and can overdub/replace/insert audio over the sample/loop. Not too dissimilar from hardware looper/samplers out there.

More specifically I'm aiming to model it after this:

It's essentially an 8-bit, hardware, glitchly sampler/looper that can do some peculiar slicing/granulization stuff.

The reason for this, in a more global sense, is that I'm moving my setup from a hardware based system towards a software based one. Eventually it will live in a headless mac-mini "black box" style.

This is kind of what I do in general (drums + diy/lo-fi electronics):

http://www.rodrigoconstanzo.com/2011/05/life-as-an-academic/)

Now I've searched on the forum/google and haven't really found any suitable examples/patches. Most are either tempo/clock based, or not working (a lot of posts where people get help seem to often not have the 'finished' patch in the post, it's always one step away from working), or don't do the overdub part, etc...

I found in my old max patches I had saved the KaiserLooper (which looks ideal barring the lack of overdubbing), which is good as it doesn't appear to be on the web anymore? Also found a (line6) DL4 based one, which does do overdubbing, but seems to be very buggy.

If anyone knows of a patch/external/whatnot that does this kind of thing, that would be great as it would save me having to re-re-re-rewrite something like that.

So far I've started really simply using buffer~ groove~ and poke~. Are those the core objects I should be looking at in order to do what I want?

I know this is trudging through very common waters, but I'm returning to max after many years away from it (I stopped using it before max5 came out), and am having a hard time figuring out how to build what it is I'm trying to build. 

Essentially I'm trying to build a (simple) sample/playback patch that sets sample/loop length dynamically(asynchronously), and can overdub/replace/insert audio over the sample/loop. Not too dissimilar from hardware looper/samplers out there. 

More specifically I'm aiming to model it after this:
(http://www.narrat1ve.com)

It's essentially an 8-bit, hardware, glitchly sampler/looper that can do some peculiar slicing/granulization stuff. 

The reason for this, in a more global sense, is that I'm moving my setup from a hardware based system towards a software based one. Eventually it will live in a headless mac-mini "black box" style.
This is kind of what I do in general (drums + diy/lo-fi electronics):
(http://www.rodrigoconstanzo.com/2011/05/life-as-an-academic/)

So far I've started really simply using buffer~ groove~ and poke~.  Are those the core objects I should be looking at in order to do what I want?


live-samplingplaybacklooper-objects-question

don´t see the problem, [groove~] is to set up really direct (see online documentation) and overdub is nothing but mixing what you play with what you record, e.g. streaming the mix into a temp file which you load into your [buffer~] afterwards.

Also how to you determine the length of what you've recorded into the buffer? (Say I have a 60sec buffer, but only record 700ms into it and I want that to loop)

A temp file meaning another buffer?
Also how to you determine the length of what you've recorded into the buffer? (Say I have a 60sec buffer, but only record 700ms into it and I want that to loop)


a) not nescessarily another [buffer~] as you don´t know how long your recording´s gonna be. i´d recommend using [sfrecord~] for recording directly to harddisc, and when finished, read that file into the buffer with a 'replace' message (which sets up the appropriate buffer length automatically).

b) i made a little patch about recording with [record~] which cuts the [buffer~] after recording.

Would writing to disk run the risk of bogging things down if other things are happening?

This seems to work pretty well (though sometimes it doesn't seem to want to resize to the right size?)

I am getting my max window flooded with "buffer~ nothing to crop"

no, i don´t think so if you´re not recording a hundred files at once.

sorry about the little "bug", that´s just signal streams continiuosly and therefore bangs at zero again and again. i fixed it.

for what i tried it records/crops precisely to 0.1 milliseconds.

That seems to work real nicely. Thank you.

[select 0.] seems to bang the crop message on startup so there's still a single error message, though not terribly important.

I've managed to get some of the core features going, and even emulated the gritty sound of the 8-bit thing (particularly when bringing playback speed way down). Haven't figured out how to scale the volume/output appropriately to compensate for the increase in gain though.

Back to the looping. Is there any reason why the overdubbing shouldn't happen in another buffer?

That seems to work real nicely. Thank you. 

[select 0.] seems to bang the crop message on startup so there's still a single error message, though not terribly important. 

I've managed to get some of the core features going, and even emulated the gritty sound of the 8-bit thing (particularly when bringing playback speed way down). Haven't figured out how to scale the volume/output appropriately to compensate for the increase in gain though. 

Back to the looping. Is there any reason why the overdubbing shouldn't happen in another buffer?


the reason is for [sfrecord~] you have more or less open end (depending on your hard disc space), if that´s not important to you then maybe do it with another [buffer~].

That makes sense. Though would that end up leaving a litter of files behind? Or do you just create a designated file that's always used?

Also, is there anyway of getting rid of the 'nothing to crop' error I'm getting at the moment when the patch is first opened up?

yes the idea was to always record into one temp file designated for just that purpose. you don´t need diversity here as you´re gonna load and keep the recorded file in your specific buffer afterwards.

and sure, just place a [gate] that is switched via the record-button.

Hmm, not sure I follow you on the [gate], rather, I understand what you mean, but putting it in, it seems like it closes the gate before the bang gets sent out.

max runs from right to left, means in your patch the [record~] is triggered before the [gate] is opened which is the false order.

right-left order . . . (just seen other reply but here's some thoughts anyway)

do you really need to set the buffer size both when toggling on and off?

also using [snapshot~] rather than [number~] might be better in the long run?

if you only ask for the recorded value when you need it, the gate isn't needed

also, if the size is explicitly set, is there any need to ask for with [info~]?

lastly, I've made crop automatic, but I don't know if you'd want this...

also using [snapshot~] rather than [number~] might be better in the long run? 

if you only ask for the recorded value when you need it, the gate isn't needed 

lastly, I've made crop automatic, but I don't know if you'd want this...


the size-set is for initialization, you have to seperate it via [sel 1] otherwise you probably delete the [buffer~] after recording which doesn´t make much sense. thanks for the hint.

the [info~] is potentially for flexible buffer sizes, you don´t need it if always using the same size. i think he was asking for something like that at the beginning of the thread.

using [number~] seems to be more compact here, isn´t it?

Howdie Sam. Having dynamically set sample size is central to the patch.

Sam's version appears to work dynamically (although it seems to break under certain circumstance). I think it's when I'm reading something into the buffer (which will not be part of the final thing, it's only there to test things).

As far as the overdubbing thing goes, I saw mentioned in this thread:

https://cycling74.com/forums/syncing-multiple-loops-using-groove

That you can play/record the same sample into the same buffer at the same time. (They mention "AndrewB's index~/poke~ patch" which I had no luck trying to google/search for). Would that involve writing to the buffer in a fundamentally different way? (poke~) or would that just be for subsequent overdub oriented tasks (once the buffer size is set).

Although in thinking about it I think I would need a different buffer as part of this patch would be the ability to record live audio onto speed altered playback (so if I'm playing back at .5, and record something, it would sound as I heard it, and not hearing the new stuff also at .5 when it comes back around).

A quick question about varispeed stuff too. In the device I'm modelling my patch after, there is a fixed buffer/memory size. There's hardwired RAM and that's it. Varispeed happens at the clock level. So if I have the clock all the way up and record/playback, I hear what I played back as is. If I turn the clock down halfway and do the same thing, I hear back the audio as is (it just records it at a shittier sample rate). This allows for some nifty things like changing the clock speed while playing records the varispeed stuff INTO the buffer, which can then get manipulated on the way out too. You can also do the 'recording live audio onto slowed down audio' thing as well as bringing the speed way down, playing something, then cranking the speed up effectively speeding/pitching up the audio.

As far as I know you wouldn't have/mess with a master clock like this, so can you alter the rate with which you record INTO the buffer? Or achieve what I'm talking about through some other means?

Howdie Sam. Having dynamically set sample size is central to the patch. 

Sam's version appears to work dynamically (although it seems to break under certain circumstance). I think it's when I'm reading something into the buffer (which will not be part of the final thing, it's only there to test things). 

As far as the overdubbing thing goes, I saw mentioned in this thread:
https://cycling74.com/forums/syncing-multiple-loops-using-groove

That you can play/record the same sample into the same buffer at the same time. (They mention "AndrewB's index~/poke~ patch" which I had no luck trying to google/search for). Would that involve writing to the buffer in a fundamentally different way? (poke~) or would that just be for subsequent overdub oriented tasks (once the buffer size is set).
Although in thinking about it I think I would need a different buffer as part of this patch would be the ability to record live audio onto speed altered playback (so if I'm playing back at .5, and record something, it would sound as I heard it, and not hearing the new stuff also at .5 when it comes back around). 

As far as I know you wouldn't have/mess with a master clock like this, so can you alter the rate with which you record INTO the buffer? Or achieve what I'm talking about through some other means?


This is a patch similar to Andrews. Variable buffer loop size of 8 sec or less, set after the first recorded loop is closed.

Ok so it looks like poke~ makes overdubbing much easier. Also in looking up the varispeed stuff, it looks like poke~ is the object to use. I also saw ipoke~ which I guess facilitates stuff.

I also notice no groove~ object in there, so poke is both the record AND playback object?

I saw this post/patch and it looks kind of ideal in terms of being able to record/overdub/varispeed. It mutes the playback while overdubbing though (may just be a routing thing, I've not looked at it in depth).

https://cycling74.com/forums/varispeed-recording-question

I also notice no groove~ object in there, so poke is both the record AND playback object? 

I saw this post/patch and it looks kind of ideal in terms of being able to record/overdub/varispeed. It mutes the playback while overdubbing though (may just be a routing thing, I've not looked at it in depth).
https://cycling74.com/forums/varispeed-recording-question

Ok, so I've been rebuilding it all based around ipoke~ but I'm running into some problems. The patch appears to have groove playing nonstop, back into itself. So i can't figure out how to make it start from the beginning of the loop without it freaking out and erasing a bunch of the buffer in the process.

Also I've lost the ability to resize the buffer dynamically too.

Can I still use snapshot/select/set/crop thing but using ipoke? How would that work if it's just looping around the whole time?

Ok, so I've been rebuilding it all based around ipoke~ but I'm running into some problems. The patch appears to have groove playing nonstop, back into itself. So i can't figure out how to make it start from the beginning of the loop without it freaking out and erasing a bunch of the buffer in the process. 

Here's another version of the same patch I posted built around groove this time. Replace the poke with ipoke if you want. You'll need the scale~ object to make the patch work. 

Here's another version of the same patch I posted built around groove this time. Replace the poke with ipoke if you want. You'll need the scale~ object to make the patch work. http://richarddudas.com/software.html 


I found I could just replace scale~ with *~ and it still worked fine.

However I can't seem to get any joy if I replace poke~ with ipoke~ (this has been the case with other patches I've looked at). Is ipoke~ an exact drop in replacement of poke~?

Here's the patch working (with no scale~ and poke~), but the moment I change poke~ to ipoke~ it seems to break.

I found I could just replace scale~ with *~ and it still worked fine.
However I can't seem to get any joy if I replace poke~ with ipoke~ (this has been the case with other patches I've looked at). Is ipoke~ an exact drop in replacement of poke~?

So anyone know why ipoke isn't working in the place of poke? (I almost typed it out as "iPoke" out of iHabit)

I think I narrowed down the problem. It's the buffer resizing part that isn't working with ipoke. I used a different patch and could swap poke and ipoke out willy nilly and it was fine. It's only when I added the cropping stuff that it broke.

The bit of code that Sam posted above works perfectly for resizing the buffer, but it's using a record~ object, which is no longer in play since I have (i)poke running.

Ok, I wrestled and wrangled and finally got it working.... I feel like a climbed a friggin mental mountain.

Can someone take a quick look at this and let me know if I'm doing something in a ridiculous manner?

But before that, in terms of managing play/overdub/stop/playonce states, is it just a series of nested gates? I started building something like that, but all the exceptions became rather complex. Is there a better way to handle state management than gate?

I think I narrowed down the problem. It's the buffer resizing part that isn't working with ipoke. I used a different patch and could swap poke and ipoke out willy nilly and it was fine. It's only when I added the cropping stuff that it broke. 

Ok, I wrestled and wrangled and finally got it working.... I feel like a climbed a friggin mental mountain. 

Hi Rodrigo, I just saw this post...I'm going to post a new version of the kaiserlooper on my site soon (maybe this weekend), I just took it down for a break from being tech support for free patches. :-) If you still have the patch, you can get it to behave like overdub by building in some features, such as: after you hit play on the current track, have it automatically arm the next track to record. It is designed to add as many loop modules/tracks as you might need, so don't feel limited by the 4 or 8 that is in the example. However, if you are looking to play with everything lining up, it is not the right one: my looper is designed to keep the loops asynchronous, which is how I prefer to play.

I'd love to see the new version of it. I love asynchronous loops too, but I want to be able to overdub onto each of them. Towards that end, this module I'm working on is one of four independent ones I plan on using in the end.

I can just trigger the next module if I want the "overdubs" to be out of sync too.

I realized I forgot to make the recording time out after the max buffer length so I get a crop error if I go longer than that, but other than that, I *think* this is working right, barring logic/transport/etc...

I'd love to see the new version of it. I love asynchronous loops too, but I want to be able to overdub onto each of them. Towards that end, this module I'm working on is one of four independent ones I plan on using in the end.
I can just trigger the next module if I want the "overdubs" to be out of sync too.

I realized I forgot to make the recording time out after the max buffer length so I get a crop error if I go longer than that, but other than that, I *think* this is working right, barring logic/transport/etc...


I take it back, my patch is quite prone to crashing. Hmm.

I suspect it has something to do with this weird DC/cycle offset I'm getting at the start of most buffers.

Ok, I've completely rewritten the patch. It's super tidy, encapsulated, annotated, with the problem outlined in red text.

As per a friends suggestion I'm no longer cropping the buffer in order to resize things. I'm using count~ to set the max loop time of groove~. This is working nicely.

I'm also trying to decouple groove~ from ipoke~ in terms of sync. I was driving ipoke~ with groove~ using a trunc~ object before (nabbed from some examples posted above). ipoke doesn't seem to like this.

I can manage to record into the buffer with ipoke~ but the moment I try to resize it all falls apart. I've yet to be able to resize a loop when ipoke~ is involved at all. (Some other examples I've found on the forum have that weird DC/cycle thing happening too).

Ok, I've completely rewritten the patch. It's super tidy, encapsulated, annotated, with the problem outlined in red text. 

As per a friends suggestion I'm no longer cropping the buffer in order to resize things. I'm using count~ to set the max loop time of groove~. This is working nicely. 

I think it's not a DC offset thing you are experiencing....its probably having interp = 1 and jumping from one location to another quickly with ipoke. It's interpolating between two values over the entire range that is skipped. I've been wrestling with this in my own looper lately, but haven't found a good solution yet.

I think it's not a DC offset thing you are experiencing....its probably having interp = 1 and jumping from one location to another quickly with ipoke.  It's interpolating between two values over the entire range that is skipped.  I've been wrestling with this in my own looper lately, but haven't found a good solution yet.


Yeah that was the problem. I ended up going with poke/groove in the end.

Between that post and this I got a version going with ipoke that let me dynamically resize the buffer, but I ended up dropping that too when I realized that I couldn't jump around the buffer while writing anyways.

In my particular looper I never went above '1' for speed (only dropping below, then back up if I wanted to pitch it up).

Here's the final version (as a standalone, in my full patch it does more, including the 'reverse while you record' stuff).

So it's using poke/groove to dynamically create a loop (up to 30sec). You can varispeed at any point (even while recording).

It has all sorts of noise/click removable stuff built in, as there's weird circumstance that pop up using this method. For example, crossing the 0 point while overdubbing would cause a little click. This is mainly due to having groove/poke synced up (using +/- 3 samples depending on direction).

I got massive forum help for this, particularly from christripledot.

Check out this thread to see more info on it (and his version of the final patch):

https://cycling74.com/forums/zippergritty-distortion-when-writing-with-pokeipoke-backwards-groove-sync

Yeah that was the problem. I ended up going with poke/groove in the end. 

Between that post and this I got a version going with ipoke that let me dynamically resize the buffer, but I ended up dropping that too when I realized that I couldn't jump around the buffer while writing anyways. 

In my particular looper I never went above '1' for speed (only dropping below, then back up if I wanted to pitch it up). 

It has all sorts of noise/click removable stuff built in, as there's weird circumstance that pop up using this method. For example, crossing the 0 point while overdubbing would cause a little click. This is mainly due to having groove/poke synced up (using +/- 3 samples depending on direction). 

Check out this thread to see more info on it (and his version of the final patch):
https://cycling74.com/forums/zippergritty-distortion-when-writing-with-pokeipoke-backwards-groove-sync

Hi, I just stumbled upon this thread and saw a while back you referenced a thread and patch I posted.

I just wondered if you spotted the bit about setting the buffer in ipoke to a dummy value when you want to stop recording or move to a different index.

Maybe no good for you but it helped me out!

Seems like you got where you wanted anyway but just thought I'd mention as It confused me for ages.

I've been trying to implement your looping patch into this vocal effects patch I'm working on at the moment.

Everytime I bring in your patch and turn on the dac~ in the main patch it crashes Max. See patch below. Turn on DAC and Max will crash. Have you any idea why this is happening?

Hey MickOR, just now seeing your post. The combined patch doesn't crash on my system. Did you try subtracting modules to find which didn't work with my patch on your system?

I've started playing a bit with Rodrigo's looper patch but I'm often having one little problem.

Sometimes, as the overdub record goes through the first loop, I'm getting a little high pitched glitch that is getting bigger everytime I record on it. I tried some ramp and line stuff to kill the signal just before the end of the first loop but nothing seems to work well so far.

Hey howdies, kinda new here.
I've started playing a bit with Rodrigo's looper patch but I'm often having one little problem.
Sometimes, as the overdub record goes through the first loop, I'm getting a little high pitched glitch that is getting bigger everytime I record on it. I tried some ramp and line stuff to kill the signal just before the end of the first loop but nothing seems to work well so far.

Have you tried Rodrigo and Raja's Karma looper? It doesn't have the issue that you are finding with the older patch. Info here:

https://cycling74.com/articles/get-the-karma-package-by-rodrigo-and-raja/

Live Sampling/Playback/Looper objects question