karma~ (sampler/looper external)

How did I not play with this object until today. karma~ is cool!

Good stuff!

I loved the demo and wanted to experiment building gesture interfaces, but did anyone succeed compiling karma~ with MacOS Mojave? MacOs does not allow 32-bit targets. Any alternate source compiles with xcode?

Hmm, not messed with the latest xcode, but there is a (super beta) karma~ 1.5 on github if you want to try that: https://github.com/rconstanzo/karma/tree/master/karma%7E1.5

Rodrigo, I did try karma~ 1.5 release too. Had the same error as in object not found. I downgraded to High Sierra and it works like a charm. I'm not sure which part of Mojave (xcode probably) is messing it up. Either way, thank you and as always, amazing external here.

Hmm, that's weird. It works fine for me in mojave, but I don't think the build I have was built *in* mojave, so could be that?

Glad that it's working at the moment though!

It is just great! really like it...

Thank you very much Rodrigo...

Hello - I love karma~ and am grateful to you, Rodrigo, for making it! One question I have: is there a way to stay in "record" mode without switching to "play" mode automatically after the initial pass? once I hit "record", I would like karma~ to keep recording and playing - without overdubbing. Many thanks

Not sure I follow.

So starting from an empty loop and nothing happening, you want to hit "record", and have karma~ start recording. Then do you want to define a loop point by hitting "record" (or "play")?

Wait, I think I get it. If you send a message of "overdub 0" to karma~, you will just replace the loop (instead of overdubbing) each time you go over the sample.

Thanks for your reply. I am trying to emulate the "loop record" mode in the record~ object. I'm not concerned with loop points, I just need karma~ to keep recording as it plays back whatever already exists in the buffer. Starting with an empty buffer, I've noticed that after the first time I hit record, once the buffer is full, karma switches to playback mode and stops recording. Like you say, with "overdub 0", if I hit record again after the initial pass, karma~ will stay in record mode, while playing back the pre-existing audio. So I think I've figured out a workaround - once I hit record for the first time, I send a second bang, delayed by the length of the buffer, to the record message, and this seems to be working.

Oh I see.

You can also use karma~'s outlet to hit record automatically, something like this:

But if what you want is the behavior from record~, you can always use record~ to record, and karma~ to play.

Or you can use @raja's rezer~ object which has separate record and play heads in the same object: https://cycling74.com/forums/-ann-rezer~-looping-external-like-karma~-but-w-sample-accuracy-now-beta-testing

I have been using record~ with karma~ but I get pops and clicks when working with long tones in loop record mode. Sounds much better if I can do everything just with karma~. Will also check out rezer~. Thanks so much for your help.

amazing!

Hi, I cannot seem to get karma to work without the help file open. it will not record to a buffer unless the help file is open, it usually replaces my sound with sounds from the help file. can anyone help with this?

I suspect you haven't created or copied over a [buffer~] object.

karma~ needs a buffer to write to in order to work.

hmmm weird, I did rename the buffer and made sure the waveform~ had the same name. fixed it (sort of) by coping the basic code from the tutorial and it all seems to be working now with my add ons.

another question, does karma need the waveform display to work?

Nope, doesn't need the waveform. That's just there to help visualize things.

Also, I realize that the way it's setup isn't ideal for changing things as it's behind several layers of UI stuff. That will change with an update at some point.

No worries! Definitely keeping my eye out for the new version, karma is insanely easier than groove will hope to be. totally fine with using the format you have in the tutorial just wanted to dive a little deeper into it! Thanks for this awesome object!

Hi. I am having problems getting Karma to work. I'm on 64 bit Windows version of Max 8. So, after defining a named karma object, creating a buffer with the same name will cause Max to crash. I've tried it several times but it simply refuses to work. At times it won't crash but inputting an external signal and hitting record won't write to the buffer. The buffer remains empty. At other times the audio will glitch out completely and hitting record or stop causes it to crash. I have signal probe enable and can confirm that signal is going to karma's input. I have even defined a name buffer first and then karma but still it won't work. The help patches for karma works fine as is and will even let me record external signals to the already defined buffers in the help patches. But, as soon as I copy them over and/or change the buffer names, it stops working or crashes. If I load an external sample using read or replace directly into the buffer and hit play on karma, it throws the error "can't read the file now". I have double checked everything and can confirm that I'm giving correct names/number of channels to Karma and buffer . (karma shows an error if an associated buffer is not defined in the sidebar) I downloaded Karma from the package manager in Max. Please any help is appreciated! Thank you! Also, I'm a beginner max user.

Hmm. I don't have or use windows so it's hard for me to test anything with it.

I don't know if you can force it to launch in 32-bit mode on windows, but that could help rule things out (I think it's a pretty big fork in the code depending on that).

Also, what happens if you create a new patch with a karma/buffer combo, save the patch, and then reopen it. Does it crash still? Does it work?

Has anyone who uses karma on windows run into any similar issues?

Hi thanks for the reply. Yes it still happens. I was initially working on an older patch trying to replace groove objects with karma. that didn't work out so I started from scratch in a new patcher just with basic signal input,buffer,output I still couldn't get it to work. It just crashes or just won't work. :(

Yeah without being able to test things it's hard for me to go further or know what to suggest. It's strange that the helpfiles still work.

Can you maybe post a small section of patch that crashes for you and I'll take a look.

Hi. I'm attaching a screengrab of a new patcher in which I recreate the problem. I'm also uploading the patch.

As you can see the buffer remains empty and in the end when I define a new buffer, max crashes to desktop.

A right, a couple big problems in the code.

The first is that karma needs an input to it's right inlet (like groove), so with nothing plugged in, it is recording at a speed of zero, so nothing happens.

The other big thing is that the buffer you created is 2ms long (and only one channel). For buffers you want to give it a name, a duration and then the amount of channels.

Here's the code for that (you can copy this, then open Max and select "new from Clipboard" from the File menu.

Thank you so much. I feel stupid for the obvious mistakes although I didn’t know about setting the recording speed before attempting to record.

Also , you have set the maximum limit for the buffer as 5000ms. Can I somehow dynamically set the buffer size according to how much I want to record? I mean I hit record and hit stop after a certain period of time without having to think about the maximum limit of buffer?

No problem. We were all noobs at some point.

Whatever you set the buffer to will be the maximum you can record. Each individual loop you record will, internally, set its own loop length.

What I normally do is set it to something much bigger than I would need (often 60000 or 300000 if I want the extra size). That way you don't have to think about it, you just record for as long as you want without having to think about it.

Hi Rodrigo. I've been trying out Karma for the past few days and seem to be getting the hang of it. Can you tell me a way to implement a 'pause' and 'resume' function?

You can do something like this.

Code is a bit messy, but it gets the idea across.

Hello Rodrigo - I love karma~ - thanks for making it and for being so generously helpful to everyone in this thread. I am encountering a version of the "can't read file now" problem. Using only Max 8 (not M4L) on a Mac. I want to be able to switch back and forth between recording into karma and loading existing samples into its buffer. I can initially read files into the buffer associated with karma no problem. However, if I record into karma~, and afterwards, want to load a new file into the same buffer, I get the "can't read file now" message. It's like the record function renders the buffer useless for any further file reading. I can recreate the problem in the karma~ help file as well. Posting a screenshot. Any idea how to work around this?

You can try the 'replace' message instead (which is better since it loads the entire file you are trying to load, whereas 'read' only reads as much of the file as will fit into the size of your buffer).

From what you're describing, however, I think you need two karma~ objects, and then you just switch between whichever one you want to play back. when you record into karma~ it behaves a bit differently than a "normal" playback object in that it only plays back the part of the buffer that you have recorded into. Generally speaking, when you load a file into a playback object, you want it to play the whole thing, or have access to the whole thing.

It wasn't so much a read vs replace problem - no method of loading a file into a buffer that had been previously recorded onto was working. I took a suggestion you posted earlier of working with two buffers - one for recording, the other for loading samples. I set the name of the karma object depending on which buffer I want. It's a good work around. Thanks!

That's another thing you can do too, just to refer to it.

karma~ 1.0 doesn't handle "dirty" buffer stuff too elegantly unfortunately. A future one should make that kind of stuff more possible/easy.