Live Looping in 2026 - Object suggestions for a novice

you can do all that with plain max objects.

easiest part is getting audio record and playback to work,

most work is to get arround loop states and logic arround it.

Thanks for chiming in. I've seen your contributions to the various looping threads and they have been very helpful!

Which "plain max objects" would you suggest I look into? I have seen mention of poke~ and index~ but have yet to dive into them. Any others?

Thanks in advance!

P.S. are you the "SOURCE AUDIO" responsible for the pedals? Love your work if so.

this book will be released for free soon

Thanks for that, I had a look at Jeff K's website and I believe a version of this text is available for free there.

https://technophony.com/building-live-loopers-in-max/

I did read it over and worked through the examples . That said, I did not dig into the gen~ stuff because I am limited to Max4Live where the gen~ environment is not included. His MSP Looper examples unfortunately do not take into account sample-accurate control. They were a great entry point into the concept of recording into a buffer and playing it back though.

Came across this tutorial and have worked through it:

http://peterelsea.com/Maxtuts_msp/loopsInMSP.pdf

It has illuminated one way of achieving sample accurate looping use vanilla MSP objects, namely poke~ and index~ driven by a count~. I quite like the simplicity and can already imagine how I could implement overdubbing, and perhaps even some rudimentary de-clicking. However, I do not see any way I can control the rate or direction of the count~ and thus the playback (a la varispeed.) And in googling that I am learning index~ is not really suitable for such a task anyway, given the lack of interpolation.

I'm thinking playback using another object (like play~) is necessary here, but this necessitates the use of phasor~ which really does my head in... scaling it, using it to dynamically loop only a portion of the buffer, and so on, confuses me greatly.

If anyone has any suggestions on where to direct my research it would be greatly appreciated. The hard part about MaxMSP is that it is so flexible it is difficult to know where to even start!

EDIT: the more I google the more I realize this is all very well-trodden ground. Thanks in advance for your patience with my skill level!

yes, that´s how it is: index~ based solutions are superb - as long as you do not need to change pitch.

the floating point equivalent to count~/index~ would be line~/play~.

objects like play~, groove~ or wave~ perform a value interpolation for you already internally in the object.

to learn (and to transform the count/index stuff you already have to a "float version"), start with play~.

no, I am not associated with the pedals company.

it just happened that they picked same name as my nickname here...

I was involved in development of hardware loopers from early days of looping,

and developed many max based looping devices in last decades.

If I can suggest, first list all you want from a looper.

that will route you to objects that could satisfy your needs

without gen~ objects.

something like reversed, speed changed overdubbing

in synced multitrack looping ...

as soon as you want that, you are in a trouble.

interpolation, out of sync etc etc

I was never interested in that, just plain , clean looping

with as many synced tracks of different lengths, undo, redo and so on.

synced polyrhythmic delays and such things.

in one or the other way you will hit the wall if you want both.

None of looping objects you mentioned satisfied very basic looping

needs for me, like latency compensated overdubbing,

crossfaded loop start-end and synced multiple tracks.

without that it simply does not work for serious live looping.

.......

sample count needed for index or poke can be converted from range

or miliseconds outlet of other objects using mstosamps~ for example.

......

I used xsample~ buffer based recording and playback objects quite often

becasue they offered sample based sync between play/recording heads

and made construction easier then having to use several max objects

for same task.

there are updated versions, help files are really outdated ...

https://github.com/jpsteccato/xsample

p.s.

if you find solutions based on that book:

https://technophony.com/building-live-loopers-in-max/

maybe you can port it to rnbo~ and compile your own external(s)

Thank you both for your insights!

@roman

I was having a look at play~ last night and can immediately see how it is more appropriate for playback where a rate change is required. However, it is hard to wrap my head around what will be necessary in order to have a playback "head" and record "head" (currently driven by count~ into poke~) that remain in sync with one another when play~ is employed. It's easy with a count~ driven patch since the count~ controls both "heads" simultaneously. But since play~ expects milliseconds and count~ outputs samples, I either need to do a unit conversion (which apparently is error-prone due to rounding) or find an alternative method of sync'ing the "heads."

It would seem my predecessors conclude that using phasor~ is the most appropriate clocking method. But that raises some questions in my novice brain:

• would I need to substitute poke~ for another buffer writing object, considering poke expects a sample index, and not a 0-1 signal? I suppose there's a way (with math) to convert that 0-1 to samples if the sample rate is known...

  • many example patches I've looked at employ some kind of math on the phasor~ output presumably for this reason, but the values used in the math are not obvious to me. For example, many people include [+~ 0.5] and I have no idea why.

  • there's also the use of trunc~ whose purpose is not obvious to me.

• phasor~ seems to be a free running thing, whereas a clock (or tape transport) can start, stop, pause, and be reset. I'm sure there's logic that can be built to allow for this kind of behaviour. Perhaps sample and holds?

• on the bright side, perhaps a phasor~ driven approach will allow for an easier time recording in a loop.

  • Right now, with count~ and poke~ I'm doing some hacky edge~ detection to restart poke as the counter~ loops back to 0. It doesn't sound great.

(I know these are not exactly "new" obstacles; most other people going down this path wind up at the same place. I'm personally more inclined to solve the issues independently rather than simply borrowing others' solutions, for education's sake.)

@source audio:

Thanks for your insights. It is reassuring to know that some of the obstacles I'm facing (conceptual or otherwise) are in fact fundamental to the objects available to us in MaxMSP, and not entirely a consequence of my inexperience. I think we have similar requirements for what we want from a looper, particularly artifact-free, distortion-free operation. Unfortunately, the features you've identified as problematic are also features I would like. I'm not looking for anything crazy in terms of buffer manipulations mind you, but I do need:

• the ability to press a button, start playing, press the button again and have immediate looping playback.

• the ability to then overdub upon this loop, in perfect sync with what I'm hearing

• the ability to change the playback rate/direction...

  • and then overdub more material that plays back at the rate it was performed, like a tape machine.

• the ability to sync between multiple loopers

• less important, but would be nice, is undo/redo

As you say, it might be a bit of a tall order using what is available to us in MaxMSP. Thanks for suggesting xsample~ - it was on my radar and I will direct my attention toward it next.

Apologies for the long post; it is helpful for me to write this stuff down so I can identify what needs to be attacked next.

Thank you!

You are absolutely right to postulate on all options,

because it could become very time consuming to develop something in wrong direction.

my advice: DO NOT USE PHASOR.

overdubbing in other then original speed

will require either karma~ or gen/rnbo work.

all the rest can be done easily.

well, if you know exactly what and how you want to

manage multilooper tracks, their dependencies etc

if you slow down one looper then others must follow,

to stay in sync.

Another thing is - how is that going to work in Live ?

you want to completely ignore Live's transport ?