karma~ (sampler/looper external)
karma~ is a looper/sampler external for Max. It is a dynamic length, varispeed looper with some complex features that are explained in detail in the accompanying help file.
Here is a tutorial video showing some of what karma~ can do:
The feature set and functionality was something I conceived (and implemented a cruder version of) in The Party Van. The karma~ external has the same core functionality but super charged, lean & mean, and elegant as shit. karma~ was lovingly coded by raja, and I can't thank him enough for taking the project on!
You can download the compiled object (for 32/64bit Mac and 32/64bit Win) as well as the source code here (1.0).
You can follow the github repo here : https://github.com/rconstanzo/karma
The linear interpolation used in the recording stage of karma~ is based on ipoke~ by Pierre Alexandre Tremblay.
Download this tool
love it!
this is very good
Snap, for some reason the video didn't embed right in the post. Be sure to watch the tutorial video as it's worth watching independent of it being a tutorial video.
I edited it to show correctly, the original post didnt work.
really enjoyed the tutorial video... look forward to playing with the external.
hahaha great. I love it.
This looks incredible!
Though, I am having some trouble opening the .mxo file. Am I missing something?
Followed this address:http://www.rodrigoconstanzo.com/wp-content/uploads/2015/05/karma1.0.zip
Trying to open .mxo file from B version, on mac running OS 10.9.5 with Max 6.1.8 32 bit
Max opens, but no Karma!
P.S. As far as tutorials go, you're killing it!
Ok, got it.
Excuse me, I am an idiot.
Glad you found it!
how did you open it?
Open the helpfile that comes with it. karma~.maxhelp
You should put karma~ itself (the mxo/mxe) into wherever you put any other externals.
I've been experimenting with Karma 1.0
It works great!
However, I noticed that my playing comes back delayed... in other words, it doesn't sound like the recordings are being compensated.
Are there any plans to add delay compensation into it?
Larry
There shouldn't be any delay in karma~ at all, as it doesn't deal with real-time audio passthrough, but if you're experiencing latency in general, externals themselves don't handle any of this kind of thing. This would be something in your "Performance and Scheduler" settings in Max. Try putting the I/O Vector and Signal Vector sizes to something smaller (256/128 ir a good middle ground).
Thank you for your quick reply.
i have Max set to 128 samples and 64 vector.
So, I'm not sure why I'm getting the delay.
It's small ... 7 - 10 ms but that is a very large amount when you're dealing with quick passages in music.
I'll see if I can figure out what it's coming from.
Thanks!
L
Are you getting a delay from karma's audio, or in Max in general?
If the delay is happening when you're triggering karma you can also try having the scheduler in Overdrive (or even Audio Interrupt), as that will put the triggering in a higher priority thread.
I'm getting a delay in playback later than what I play into Karma.
For instance, I play loop 1 into karma... establishing a rhythmic loop in tempo for about 30 seconds
This loop continues and cycles just fine.
I then overdub (hit record again) and add another part on top of the original part (also rhythmic).
When I play the overdub into Karma part everything sounds in time.
But when Karma cycles back around and plays my overdub back to me, it's several milliseconds BEHIND where I originally played it.
That's what I'm experiencing anyway.
I'm using an RME interface and latency is set very low.
Overdrive is on and I've ruled out a triggering problem since it's the overdubs that are not coming back in time.
The overdubs are played several milliseconds BEHIND where I played them into Karma originally.
In other words, it sounds right when I play it INTO Karma, but when Karma plays it back, it's late!
L
Hmm, not seen or experienced that. Can you make a short audio recording (or screencap) showing the problem?
Yes, I will do that later this evening. I'm Hawaii Standard time so apparently I am several hours behind you.
L
Wow the video tutorial is so fun and creative.
This is a brilliant object. One quick question - i had a loop running via wave~, driven by a phasor. The phasor triggered a bang that starts karma recording the loop. The recording is (very) marignally out of sync (just enough that when i jump to logical divisions, it is slightly off the beat). What is the most solid way to sync a loop with the record? If theres no other way, i can just manually nudge the timing myself. Any ideas?
Since karma~ takes messages as input it can't be driven in a sample-accurate way (hence the drift you're experiencing).
One of planned updates for karma~ is to add a sync/phasor output (ala groove~) so karma~ could be used to drive other objects in a sample-accurate way.
I have to say that it is great that somebody tries to keep "Looping" in max alive.
Attempts to make looping easier have wanished since frip and
specially xsample objects.
Being very helpful for unexperienced users, frip or karma approach lack the basis of looping
which for me in first place are latency compensation, so that what you overdub comes out exactly
on same position in loop where you played it, and not less important recording crossfade (not just fade in/out) on record start/end.
That is a must have for any serious live looping.
All funky stuff with reverse, speed pitch slice upsidedown etc can be put on top if it, but
if the basics are not there...
Do you mean that what you overdub isn't what you hear back?
I've not done hard tests on this, but it always sounded fine when playing back. Will have a closer look at this.
Do you hear any dropouts at the start/end? If I record something continuous across the "end" of the loop it sounds fine wrapping around back to the start.
Please don't get me wrong, critisizing is not my intention.
It is that I find it sooooo great that You are doing all this work,
but some so important things are missing.
Latency :
The fact is that one would have to offset the Playback by i/o latency amount
to be able to do precise overdubbing.
For many players 5 - 10 ms Latency plays no role, but for fast rhytmic patterns it really does.
With crossfade I mean : connect cycle~ to karma~ input and record it.
You will hear what I mean.
Perfect loop will sustain so that one can't tell where loop start is.
I use to fix latency by having main sample count run recording part straight,
but playback part x samples in advance. (or loop size - x samps when reversing)
So You allways hear loop playback latency compensated.
The crossfade part is also easy : fade in at recording start, fade out at recording end
but recording continues from loop beginning by fade length, so that one has perfect crossfade.
Length can be adjustable, depending on instrument, or rhythmic content in the loop.
------
Ah I understand what you mean now.
That's good to know actually and I've made note of those ideas in the GitHub issue tracker.
Hi all and Rodrigo,
i'm back doin' some work on M4Live and a device using karma~.
If i try to "replace" a buffer wich karma~ is referring to i get this error in Max Window
buffer~ can't read file now
this happens even if karma~ is stopped.
thanks
a.
Is this with 32 (b) or 64?
Maybe it has something to do with M4L as in Max(7) I can even 'replace' the buffer while karma~ is playing back.
Hi Rodrigo,
i'm working with Windows 64 bit and Max 7 64 bit last version.
karma~ does not let me replace the buffer both in Max and in M4L.
karma~(b) (wich i have now compiled for win32/64 let me replace the baffer in Max but not in M4L where i have the same error 'buffer~ can't read file now.
a.
That narrows it down some.
Without a Windows/M4L setup it will be hard to test/troubleshoot stuff, but I'll add the issue to the github and will take a look at it for any upcoming updates.
Does the [set] message work alright?
Do you mean a [set] message sent to the [buffer~] object? As far as I remember it just change the buffer reference name...
I meant to karma~. It's not elegant, but you can just have a bunch of separate buffers with the audio files you plan on using, ready to go, and then [set bufferName] to karma~ to change the referenced buffer.
Or a slightly more useful, but clunkier fix might be to keep a dummy buffer which you:
1)[set dummyBuffer] to karma~
2)[replace] your "real" buffer
3)[set realBuffer] to karma~
@Alfonso
This was a simple and (stupid, on my part) mistake in the code, which you might be able to fix yourself if you're able to compile code for yourself:
simply add the line:buffer_unlocksamples(buf);
in between the following lines:
if (dirt) { buffer_setdirty(buf); } //notify other buf-related objs...
if (x->clockgo) { clock_delay(x->tclock, 0); x->clockgo = 0; }//list...found at the end of each perform routine.
so that it looks like this when you're done:
if (dirt) { buffer_setdirty(buf); } //notify other buf-related objs...
buffer_unlocksamples(buf);
if (x->clockgo) { clock_delay(x->tclock, 0); x->clockgo = 0; } //list...then recompile and you should be good to go.
(Everytime you have a line like this: "float *b = buffer_locksamples(buf);" there's supposed to be a matching "buffer_unlocksamples(buf);" line near the end after the perform routine is done doing it's thing, but i was an idiot for missing that :p)
My apologies, was an oversight when making the 64bit version.
(I was working on an update recently(found this error and fixed it in my code and was able to confirm that this worked for the 64-bit version), but then got caught up in some other business once again before i was able to finish the rest of the updates, so although i could say i'm halfway done with a newer version of karma~, it might not be ready for release until end of this year, or beginning of next.... so, since i know you're familiar with the basics of coding these externals, perhaps you can do that much for yourself, just for now, and hopefully the next incremental will be out soon.)
(The equivalent for 32-bit was this:
"if (dirt) { object_method((t_object *)buf, gensym("dirty")); ATOMIC_DECREMENT(&buf->b_inuse); } //notify other buf-related objs..."
but that's already in the 32-bit code, so if that's not working already in M4L, i'm clueless as i'm a bit out of practice these days and can't test M4L anyways).
If you still have problems(after making the changes in the fully 64-bit one as recommended above), it may have to wait(i've been extra busy and will be crazy-swamped until around mid-October or a bit later).
Anyways, at least for the fully 64-bit version, try what i wrote, hope that helps, and sorry again for the inconvenience.
(@Rodrigo, hope you don't mind me just writing/exposing this here... very 'unprofessional' of me, but hey, it's free! ;D )
@raja
Ah glad it was a known/fixable issue and not something that needed to get hunted down on a Windows/M4L setup.
And no worries exposing anything, I've been quite excited about it, so it's been harder not mentioning anything, hehe.
@R∑N∑G∆D∑ R∆J∆,
thank you man! i've just compiled karma with the additions you suggested.
It works fine in Max. I'll go check in the next minutes/hour if it works in M4L.
Let me know if you guys need that i upload the compiled win32/64 externals and the modified karma~.c file.
@Rodrigo
thanks for the suggestions. I thought already about those strategies. The fact is that i'm restructuring an old patch/M4Live device of mine that use to have groove~ at its core, with karma~ (far more featured as a live looper engine). My device records realtime loops and save it in a folder. Every time a file is saved is added to a umenu that contains all the folder wave files. Then my device can scan the folder based on random process or via an user controlled parameter. For the [set] karma method i should dynamically create a new buffer everytime a new file is recorded. Quite a mess. But probably more reliable and time precise that [replace] on the same buffer.
I should think about that and dive in Max patcher scripting to create new buffers. Have a temp buffer to record and then as many buffers as the files present in the folder.
My device 2.0 version seems a little bit more far in the future :-) but i love challenges.
a.
ps...how do you tag people like raja here? with the @user_name formula? :-D
@Alfonso
Ah yes, do please upload them, I can upload the github repo with them. Thanks!
And yeah I figured you might have thought about some workarounds, but thought it was worth mentioning anyways.
hi guys, i wonder if you can take a look at this wich i believe is a karma/M4Live strange issue.
The new karma~ version works kinda flawlessy in Max. But in Max4Live i have several issues.
1. When i hit the [replace] message for the first time karma~ does correctly references the buffer. With previous version of karma~ gave me the buffer~ can’t read file now
So far so good.
2. When i hit the [replace] message a second time to load another .wav in the buffer i do have the buffer~ can’t read file now error as with the old karma~.
In Max i don't have this error. I have it in M4Live only.
3. In M4Live, when i try to start karma~ with my custom button i kinda hear a little click as if karma~ read a few samples than stops. This happens always. When i try to start karma~ with the plain [play] message the first time i hit it i have the same behaviour as before. The second time i hit it karma~ finally starts correctly and from this moment i can use both the [play]/[stop] messages and my custom button regularly.
Some kind of init issues related to M4Live/karma~ combination?
In Max everything works good with my custom button.
I'm uploading my initial device for testing.
Obviously for OSX a new compilation is needed on Mac with the additions suggested by Raja. Sadly i can't cross-compile.
It must be something that M4L is doing different. Will keep it in the github issues to try to troubleshoot but neither raja or myself do much M4Ling, so it will be harder to track down.
With regards to problem 3, it may have something to do with messages arriving within the same vector, which can sometimes 'break' the state machine. This bit of code will make sure consecutive messages (e.g. "play, stop, jump 0.5") are all delayed by the vector size. The problem might be something else actually, but this is an easy thing to test.
thanks Rodrigo, i'll do some tests tomorrow.
Regarding problems 1 and 2 for now i've switched to polybuffer~ using the [set] message for karma~.
Problems 3 appears in some different occasions. I have to do more investigations.
best
Awesome job!
The helpfile won't open in Max 5?
Thanks!
Hmm, I never tested the help file in Max5. Maybe it has to due with the 'tabs' interface? It's pretty self explanatory if you look at the video (or even screen shot of the help file).
Hi Everyone and @Rodrigo
I'm using karma as a sampler for a music instrument/sampler that collects sounds from records and trigger them with an interface that i m building.
It may look like a stupid question, but I would like to know if Is it possible to avoid the looping of the recorded sound. I just want a play/stop function but i don't know how to do it.
By the way thank you very much for your awesome job, it 's really f*&%in$ useful
Nico
Hi!
Yeah it's not built to do that, but it is possible to do. If you look in the "misc" tab in the helpfile, at the "basic_looper" example, there is a subpatch called [edgeDetection] which does this. Basically if there is a jump in position if you are near the start/end of the loop it presumes you are 'wrapping around' and sends a stop message.
This was done to emulate the "one shot" playback mode from the Line 6 DL-4.
Hope that helps!
Yeah is exactly what I was looking for.
Thanks a lot again
Hey @rodrigo
I am planning to use karma as an audio looper for live beatbox performances and I would like to know if there's a way to save wav files of the performance.
Instrument is an accessible mic looper designed for people with visual disabilities and works with one button for record and play and another button for stop and reset.
Do you think it will be possible to save a wav file of the performance when user will press reset button? I tried to use recorder and buffers but it doesn't work.
Any help would be appreciated
thank you again
you can save the content of a buffer~ by sending a "write" message
or have a sfplay~ before you dac to record the output
The easiest way would be to use sfrecord~ to record the complete 'performance', but if you specifically meant to save the recorded "loop", then you can send the [write] message to the buffer, but that will write the complete buffer. Which, in most cases, *won't* be what you you record.
For example, if you have a 10second buffer, and you record a 1second loop, sending a [write] message will save a 10second audio file, with 1second of audio and 9seconds of silence at the end.
The solution to this would be to [crop] the buffer right before saving, but as I just discovered, karma~ leaves the buffer as 'dirty' meaning, it doesn't let you [crop] the buffer.
But this would have been the solution to that, if that's what you wanted.
If that is what you want, you can probably get around it by using mxj stuff to copy the karma~ buffer into a new buffer, crop that different buffer, and [write] it from there.
If, however, you just wanted to record the performance, just sticking an sfrecord~ at the end of the signal chain is what you want.
I have added a buffer copy and crop to Rodrigos Patch, using only max objects.
One would prefer some kind of automated write messages in live situation,
rather than sending write message and naming the files .
That can be added if buffer storage is what You want.
Yeah that's a better way. And using only one variable for [crop] will work fine as long as you don't do any 'reverse recording' (start recording a loop while in reverse), otherwise you'll need both the start and ending values of the loop.
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.
Published
Author