Karma~ 1.0 (sampler/looper external for Max)

Here’s v1.5. Unless you have a specific need/issue, I wouldn’t recommend using this over the release version as there’s different bugs/issues/functionality.

(this isn’t directed at you @ehg, but rather people who may just come upon this thread)

I’ve also included a (super messy) patch that shows a bit of the new functionality. There’s an attribute for @sync out (for driving other playback objects), you can setloop stuff, to arbitrarily define a “loop” section of the buffer. (handy for resizing the loop you already recorded), and there’s an extra value coming out of the list outlet which shows the current state of karma~ (very handy!).

karma~ v1.5q.zip (81.7 KB)

1 Like

Thanks so much for this. Just tried it out and… I get exactly the same problems. It works as intended if I open in Max 8 Runtime, but not if I open it within Max For Live. Clearly there’s something uniquely screwy going on as a result of using those two together. In case it’s of any use, I’ve noticed while trying to get 1.5 to work that I get the same results no matter which inlet I send the record / play / stop messages to.

What a drag… looks like I’m going to need to work out how to re-authorising my copy of Live 9, or come up with some other solution. Oh well!

Have you tested it in native Max but with “scheduler in overdrive” turned on?

M4L forces that option, as well as 128/128 I/O size (if I remember right, or maybe 64/64).

Yep, checked and overdrive is on by default in my standalone installation of Max 8. Let me know if there’s anything else I can test to work out what’s causing it.

If you can make a little video or something I can point to, I can add it to the github issues page.

Hi, @Rodrigo. First of all, as I’m sure you’ve been told before, you and raja have designed a truly awesome tool. So thank you for that.

Now, I need some help figuring out what in tarnation I’m doing wrong in a patch I’m currently putting together. I’m very, very new to patching in Max, so please excuse any and all ignorance.

In my mind, I’m trying to do something very simple: a patch consisting of four karma~s to create a quadraphonic four-track looper. I’m doing this by copying the kitchen_sink example into four separate subpatches where I’ve replaced the audio looper and ezdac with an inlet and outlet—pretty basic.

Now, I would think that if I changed the buffer name in the buffer~ and karma~ objects, along with the names for all sends and receives, that I would get four working iterations of the kitchen_sink setup. And to a degree, that is what happens. However, it’s only the original, non-renamed patch that seems to work fully.

The main problem with the subsequent patches (those where I’ve changed buffer/send/receive names) is that the waveform UI goes all funky. For the most part, all of the audio functions as it should. I just don’t get the graphical feedback that is so helpful.

What tends to happen is the waveform that fills the UI will either a) not show up at all, leaving a blank black UI; b) not appear while recording but then show up when I send a play message, but when it does show up, it doesn’t populate the whole UI from beginning to end, instead showing a big blank space after the waveform, as if amend is on, though it still plays the audio as if it is filling up the whole UI—in other words, it’s playing back audio but not lined up with what the visual waveform would indicate.

I’m trying to figure out what I’m doing wrong here. To reiterate: The only change I’m making to the patch is to remain 1) the karma~ and buffer~ objects; 2) the receives going into the karma~ object and in the p posWin; and 3) the sends for position/window, autoJump, overdub, and append.

Is there something I’m missing?

Thanks for any and all help you can offer.

(I realize that might be a bit confusing in written word, and it would likely help if I would post that patch. I’m away from my computer with the saved patch currently, but I can share it later this evening.)

1 Like


So from what you’re describing I suspect you might not be renaming the underlying waveform~ objects from the help patch. They are kind of buried beneath a few layers of stuff, so you can check out this video here (specifically starting from around 4:08):

When making the original help files I didn’t anticipate what a pain that would be since most people would likely just copy/paste straight out of the help file.

The good news is that for karma 2.0 (which has been in the works) this will be handled much more elegantly.

But for now, have a look at that and see if that’s what the problem was.


Oh! Very nice! I’ll give it a try when I get home tonight and let you know how it goes.

Thanks a ton for your help!

1 Like

Took me a minute to get back to my computer for this, but it worked! Thanks a ton!

1 Like


Maybe you can help with this. Karma is absolutely wonderful, but I’m having a wee bit of trouble with a patch I’m building.

I’ve add the capability to randomize buffer position and window size. It works great on the left looper. However, while the window size and position are being randomized on the right looper, the playhead still moves linearly through the buffer and doesn’t track with the randomized position. Any clue why that might be? Everything else is working fine.

Nothing fancy in the randomPos sub. Just a metro, some random, and some scaling.

You did good by renaming the send to s k.position2, but you still need to keep the message boxes above it the same (position $1 & window $1). Those messages are key words to karma and can’t be changed that way.

The rest, from what I can see, looks fine.

1 Like

And that was it! Hah, quite the simple fix!

1 Like

Thank you so much @Rodrigo for sharing this external. It’s amazing and makes it so easy to make overdubbing loopers in Max/MSP.
I’ve read somewhere in the topic that a Pure Data port was considered. Has it happened ?

1 Like

Not that I know of. I don’t know how complex the task would be, but the code is all on github (along with a 1.5 version, which is a stop gap to the complete rewrite that is 2.0).

1 Like

Thanks. I have no idea how to make pd externals. Maybe @someone does ?
Is there a compiled karma~ 1.5 somewhere available ? What kind of improvements does it have compared to 1.0 ?
What can we expect from 2.0 ? Do you need testers ?
One thing I noticed on 1.0 is that engaging overdub produces a small “soft click”, even with zero signal going in. It’s not dramatic, but can be annoying when doing several passes.

1 Like

There’s a compiled version of 1.5 earlier in the thread. It’s not super documented, though I think I included my test patch in the zip which shows a lot of the new messages it takes.

There’s a bunch of bug fixes and code refactoring but the main new/different things in it are the ability to have a @signal out for position, so you could use it as you might use groove~. And it also takes a variety of setloop messages, so you can programmatically define loop start/end points, which you could only previously do by manually record-ing and play-ing a loop.

2.0 will be a complete rewrite and overhaul (to make maintenance and future updates easier). There will be loads of core improvements, like removing clicks like you’ve mentioned, as well as hopefully having some time-stretching capabilities. There will eventually be separate objects too (karmarecord~, karmaplay~ etc…), to make it easier to use in contexts where syncing is important, and/or if people like the transport but not the playback etc…


Looking forward to this, thanks for your hard work :slight_smile:

1 Like

Nice !
The signal out for the playing phase is indeed very welcome. Would you advice “upgrading” to 1.5 if it was just for the signal output and the recording status, or might there be some new bugs ?

Not all bugs are fixed, and there may very well be new ones that I’ve not found, but I’ve used v1.5 exclusively for the last couple of years with no issues.

1 Like

That should do it, then. Thanks again.