karma

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. It is used extensively in my xbox controller patch, Cut Glove. 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

You can read about the background of karma~ by clicking here.

The linear interpolation used in the recording stage of karma~ is based on ipoke~ by Pierre Alexandre Tremblay.

21 Comments

  • just i need ,thanks!

  • I have a project… now I think have the where-with-all. In return for your Karma~, I send you love and good wishes. Thank you. S.XX

    • You’re welcome!

  • Hey Rodrigo,

    Thanks for all the work you’ve put into this, I know ’cause I’ve been following it’s evolution for a while now on the forums. I love how seamless and not clicky it is. I gave my own shot at a Max looper here (http://www.maxforlive.com/library/device/1440/timestretch-looper) before groove~ had timestretching. Thought you might like to see it. Of course, the most awesomest thing would be if karma~ did time/pitch shifting, but that’s a whole world of mess so I understand if you don’t want to go there :)

    Best,
    Jesse

    • Glad you dig it!
      Yeah that’s something we talked about a bit, especially since Max7 came out in the middle of the karma~ dev process. There’s some long/complicated reasons why it wouldn’t be as well implemented as in the native groove~ algorithm (due to licenses), but perhaps at some point in the future karma~ might have a mono version of it or something. Don’t hold your breath though!

  • Really cool. I have a project that needs something like this. BTW, Max 7.1 has a package manager. You should submit this.

    • That’s good to hear!
      And one step ahead of you, I’ve submitted it as a package to c74, so it should show up in their thing soon enough (they are working through a backlog of people submitting packages).

  • Hello Rodrigo, I would like to move from my performance looper that I was programming over a year with the moebius looper (www.circularlabs.com) to max7. It is basically a copy of Time Exiles looper (https://www.youtube.com/watch?v=UGT1tZT9C1o). You see the concept of the looper within the first 5 seconds of the video.

    The looper is a dynamic looper who takes care that after recording the initial master loop where the BPM is calculated all following separate loops are a measure of the initial one. So you can hit record anytime and push play anytime and your loops are always in sync.

    So I have seen you Karma Patch which I would like to base my development on: Here are my questions and I hope you can give me your advice about it:

    – Is it possible that I have e.g. multiple instances of Karma running in parallel that run completely in sync with a master loop, the first one that was recorded (e.g. if i then would have a global control changing the speed of the master loop would all loops stay in sync ?)

    If this would be not possible I need to get down the path and start from scratch ;-)

    But was shocked to see how much code there is ( I saw over 1000 Lines of Code). If I compare my full fledged looper with yours (I have about 200 Lines of script code) I am questioning if I should go down the path with Max.

    My assumption before seeing Karma was: I would need to go down with the gen object as the other simple buffer objects can not get single sample accuracy.

    I would then just need to record the master loop sample (start stop), manage that is doesn’t click and then take care that all following loops are a measure of the master sample (be it 2, 4, 6,… times larger or smaller / my script code from Mobius is already available for this).

    I assume I am seeing this too simple ….

    Looking forward for your advice.

    Jo

    • Jo,

      Good to hear from you!
      Yeah that looks really great. Some of the ideas in karma~ were inspired by the Oberheim EDP I owned many years ago.

      Now karma~ does a lot of crazy things, but sync isn’t one of them. Since I don’t really make beat-oriented music, having multiple loopers in sync weren’t a priority for me at all. You can send messages to multiple karma~’s at once, but it wouldn’t be sample accurate. This is something that has been requested a bunch, so it might be revisited at some point, but at the moment, it’s not possible.

      You might be want to keep your eyes peeled on raja’s posts on the cycling74 forum (like this one https://cycling74.com/forums/topic/a-wee-share-ipoke-in-gen/) as he plans on making something similar to karma~ but in native gen~ code, allowing for sample accurate sync (something that’s important to how he approaches music).

      The last bit you mention is similar to the “Multiply” function of the EDP (and similar loopers), which I was looking at too, but it was also low priority. Again, might be revisited, but at the moment, it isn’t possible.

      Basically, there are some tools that were EDP clones already (Sooper-Looper), so I didn’t feel a need to recreate that. Instead, karma~ is based on dynamic/varispeed looping. Most of the code-based deals with that, as it’s quite complicated to do varispeed while recording (you have to either interpolate missing samples, or average/accumulate samples). Plus features like append and reverse-while-recording are quite esoteric (and complicated!).

      So your best bet might be to try the gen~-based version of ipoke~ (part of the core of karma) and try building out from that.

  • Thanks for your advise.

    BR

    Jo

  • Hallo Rodrigo, first of all thanks for this amazing object and video tutorial!
    I was wondering if it’s possible to use other buffers names rather than the ones you provided.
    I tried to do so, but then if I try to record something nothing is written into the buffer.
    So I guess there is something inside the object itself that brings a specific buffer name, isn’t it?
    Thanks a lot!

    • Hello!
      You can use any names you want, you just have to create a [buffer~] object with the name you want to use, AND then also create a [karma~] object with that name as well.

      For example:
      [buffer~ Laryssa 10000] + [karma~ Laryssa] will create a 10 second buffer, and assign that buffer to the karma~ object.

      Hope that helps/clarifies things.

  • Rodrigo,

    What a fantastic external! Thank you so much for creating this wonderful looper/sampler.

    I did have a question though. I’m a little confused about which version of karma~ to use. I’m on MacOS and my computer is 64bit. I read you readme about the difference between .mxo and .mxe as well as the information about the different versions. I’m not sure whether to use the (64) version or the (b) version. Along with this, there’s also a .mxo file outside all the folders (just named “karma~”, so I’m a little confused about which one of those to use.

    I’m a relatively new Max user, so I would tremendously appreciate your help with this Rodrigo.

    Best,

    Maks

    • Thanks!

      Either version will work fine for you. Basically the (b) version is the “(b)oth” version, so it works in 32 and 64bit. The (64) version is purely 64bit and will not work in 32bit Max. The .mxo that is just there loose is the (b) version, so one can just get up and running with that one. To double check karma~ always prints out which version is running to the Max console so you can see it there.

      (There are some small difference in the 64bit one that should make it work better in a purely 64bit environment, so if you’re only making patches for yourself, and you only ever use 64bit, that version would be the one to use).

      Cheers!

      Rodrigo

      • Rodrigo,

        Thanks for the quick reply!

        That makes sense. In that case, I’ll just delete everything in the “karma1.0” folder except “karma~.maxhelp,” “karma~.mxo,” (the one found outside of the folders) and “README.md.” This should work then.

        One other thing. You have many “multislider” objects layered on top of one “waveform~” object to create the visual. Is there a good way to reproduce this again and again? The easiest way that I have found is to copy your initial material, and then open the info panel of the “waveform~” object and change the name of the buffer it receives. This seems like it takes a little bit of time though so I wasn’t sure if there was a better way to do this.

        • Yup, that should do it. You don’t actually need the README.md either, though it may be handy to have for the links and stuff.

          As far as the waveform display, yeah it’s a bit clunky if you want to use a different buffer name. The best way to do it is to do what Sam does in this tutorial video (https://youtu.be/sxFKlYXhZ4g?t=4m8s) in that you hold shift while clicking the down arrow so the multislider/rsliders move down in bigger jumps, then once you can see the waveform~ object, change the name of the buffer, then select all the windows you moved, and shift+up-arrow to move them all back together.

          If you’re not using the position/window controls you don’t need the rsliders, in which case you can just use the multislider and waveform~ objects only.

          • Rodrigo,

            Thank you for your response. I actually did exactly what Sam did in that video. It ended up working just fine.

            A big thank you once again for all your help!

  • hello rodrigo,
    thanks for this fantastic object.
    i did a subpatch that should provide communication with the waveform UI
    without the other stacked UIs and thought i share it here…
    best
    klaus

    • Klaus,

      Thanks for this! This is quite handy. It acts a bit funny when you ‘wrap around’ the end (window > (1 – position)), but it’s definitely more elegant than the stacked multislider solution!

  • first of all, thanks for your amazing work, been drooling for months now on your webpage and your projects…I am in the process of leaving behind proprietary technology, in favor of a more personal DIY approach…anyways, my question is based on ignorance, and i apologize for it, but then again, asking is one way of eliminating ignorance. I.ve been experimenting and playing with karma, is great, I used it with various sound sources, but with guitar I am getting interesting results, so I would like to use a midi pedal board. Have a friend that offered to lend me a soft step, which I see is implemented in the party van. What about karma? I know my ignorance resides in not knowing how max can generate midi mappings, but I am eager to learn, so, for controlling karma with soft step, should I somehow patch/create my own midi implementation? thanks in advance and once again, great work Rodrigo!

    • Hi, glad you like the stuff, and karma~!

      Yeah you can totally do MIDI mapping, and Softstep mapping quite easily. I use Jeff Kaiser’s awesome jk.softstep abstractions (in The Party Van, and in general). Makes programming with the Softstep much easier all around. If you download the zip from Jeff’s webpage the main patch explains how stuff works with it.

      Enjoy!

Leave a comment

ABOUT

Rodrigo Constanzo
-makes music and art
-lives in Madrid/Manchester
-is a crazy person

Learn from me (for free!)

I am offering free lessons / conversations / consultations / mentoring / time / support to creative people, locally or remotely.
Want in on this?!

Read my PhD Thesis!

////////////////////////////////////////////////////////////
Composition, Performance,
and Making Things,
sitting in a tree :
Me-Me-Me-Me-Me-Me-Me

////////////////////////////////////////////////////////////