karma~ (sampler/looper external) beta
<>
So here's a Max external that I've been working on with raja (RajaTheResident... on here) for several months. It's pretty much ready to release. I've made a thorough help file, and am in the middle of doing a tutorial video, but for now, I want to do a mini release here on the forum to see if anyone can find any bugs or anything either one of us would have missed.
The external is called karma~ and it's basically a mega looper. For those that have been on the forum for a while will know that this is something I've been working on for a while with vanilla Max objects. It will make up the core of my patches that use live sampling/looping. I'm really happy with the feature set and implementation. It's going to be released openly/freely (including source) once it's fully released. The source is included in the attachment as well.
There are 2 versions of the external included (along with the help file). The (b) version is the 32/64bit version that will run in either version of Max (5, 6 or 7, or 32 or 64). The non-b version is a purely 64bit external. The features in both are the same, it just has to do with how things are calculated internally.
It's mac only for now, but once it's being properly released there will be a win version.
So please, test it out, and let me know what you think, if the help file/examples makes sense, and most importantly any bugs you run into. If you do find a bug, make note of which version of the external you are using (it posts to the Max window), and what version of Max you're using (5/6/7 32/64).
Enjoy!
Yum. I'll give this a go as soon as I find some free time (probably this wee). Thanks for your generosity! Really looking forward to seeing what this is all about.
EDIT: Just loaded up the help file and this looks awesome. You mind if I try to implement this in a Push looper/chopper I have lying around? Some of the functionality of this thing blows groove~ (and my home cooked gen~ looper) out of the water.
Wow. That's some really amazing functionality.
I've just started thinking about a gig where I'm planning to do some live stuff, but this has changed everything.
Great helpfile too.
Thanks.
@Evan
Go for it! The idea is to share it open/freely as mentioned above, so I'm putting it out there exactly for that very reason.
@Mark
Glad you dig it!
Do let me know if you run into any funny business. There's going to be one tiny change in the messages it takes ("set" instead of "bufr" for changing buffers dynamically, but that won't effect day-to-day usage). The final final version will also be a bit more efficient too.
Excellent! A question - I am assuming the answer is yes, but is there some stuff going on inside that handles signal incongruities when jumping/scrubbing through the buffer?
@Evan
Yup. There's switch & ramp (https://cycling74.com/forums/millerpuckettes-switchramp-reworked-in-gen/) implemented in most places to declick stuff. If you look on the 'misc' tab you can see the clicking/declicking subpatch, as well as a granular-ish example which is click-free while jumping like crazy.
Everything in the external is declicked (position/window, start/end recording, overdub/replace, play/stop, etc....)
This is pretty tasty! Nice work guys :)
I had a crash with the 'go crazy' mode in the last tab of the helpfile. Would you like me to send the report?
Yeah send it along (rodrigo.constanzo@gmail.com) though I've had the same issue with that. I might just pull that bit out of the help file, or tame it down some, as it's doing some pretty extreme stuff.
Any Mac users out there wanna post a vimeo, for us poor Windows LOSERS?
Can't wait ta see this Rodrigo
Brendan
@Brendan
You can open the help file to see what it's doing. I'm currently working on an epic tutorial vid that will show pretty much everything it does, which will be put up once the 1.0 is finished finished, but it's not quite ready yet.
@Brendan In the third world, most people have to make do with a PC , even if we could get a Mac , for many the price is ridiculously obscene . So we settle for almost the same hardware but we run it in Windows and/or/xor Linux.
Semipoor people only have "full desire " and yes.. see the video ...
Is there anyway to be honest with money from a Mac Pro in a hand, is more probably fall into the Luthier, or a merchant of vintage instruments.
Finally , beyond this comment , how much CPU uses this megalooper while you overdub for " Varispeed "?
Anyway thanks, thanks
Rodrigo and Raja!!!! and ipoke~ author...
@Barbara
There will be a windows version once it's all done done. For the moment we're hunting for any remaining bugs and then will compile to windows and have a separate windows beta test (neither one of us use or even have windows on any machines).
CPU usage is very low, and obviously varies per machine. On my old mac mini, using one instance doing all sorts of stuff goes between 2-4%.
Oh thanks!!!
@Barbara
I don't desire a Mac, whatever the price or context. And I am mainly poor. All the time.
Just very keen to see Rodrigo's hard work in action.
that's quite awesome :) been trying some times to make looper with overdub etc... this is 86970796x much better.
I have a question that is theorical and a little out of the scope of this, but maybe people here can answer, and by manipulating the overdub it came to my mind : values in a buffer are stored in 16 bits int, right ? but between -howmuch and +howmuch ? since apparently it's not -1 and +1. and what is the incremental step ? and sound comes out of max between -1 and +1, but in which format ? 24 bit int ? and the sound calculated internally of Max is either in 32 bit floats or 64 bit floats, right ? or are 32 bit max and 64 bit max completely unrelated to that...
Everything is between -1. and 1. in terms of audio. The stuff stored in the buffer is stored as floats.
The 32/64 refers to two things, one having to do with calculation and one having to do with bit depth. I could be wrong with some of the following as that stuff gets way over my head. But in terms of bit depth it effects the resolution of the numbers. So 0.0003535 vs 0.000353525253532 (those lengths are not correct I'm sure).
I hope that answers some of your questions, but that shit gets real heavy real quick.
oh. hrm. was asking because i saw that values stored in my buffer were exceeding -1 and 1, and didn't distort when read back with karma~. So that's why i'm lost when i read "everything is between -1 and 1 in terms of audio" as it should include buffer content surely?. But it can get heavy real quick indeed, i'm a bit off topic here sorry
Very impressive! Especially the reverse record feature.
I just wish this would go into the regular distribution :-)
Oooh, you mean when you use overdub values greater than 1?
In that case, I'm not exactly sure what's happening there, as this kind of stuff goes over my head.
You're such a clever dude, Rodrigo. You never miss.
@vichug: I'm pretty sure the [-1,1] is only a factor when storing to or reading from file. Buffer~'a internal resolution is floating point (I think 32-bit, but not sure since most stuff in MSP is double for signal)
I think there's a 64-bit raw file format that will store values outside of that range, but it's been a while.
Can I invoke a moratorium on the asswipe bit? Can you be the resident looper for the next week instead?
Hey hey. I didn't not post the asswipe part for any reason, it was just I know that you use several "the_resident_...." on here, so didn't want to box you in to any single one!
And yeah, feedback has been pretty great. We really hope this object makes sampling/looping sooo much easier for people in Max.
@Wetterberg
raja did all the clever coding! I was just the idea/feature guy!
The code and the feature set are equally important, imo. Shit, I have this long post of comments that keeps getting filtered here -does anyone know what's up with that? It seems to think I'm a "first-time poster"?
Nice one, thanks!
Small Find: While in play mode - Replacing buffer contents by dragging an audio file on the buffer object crashes max (but replacing via read message does not).
@raja
lol, oh yeah. the lowest!
@JKO
Interesting. I didn't even know you could do that.
It might have to do with the bufr message resetting things in the object internally, and just dragging probably doesn't do that, so all the pointers get messed up internally.
Do you get the same crash if you 'replace' the contents of the buffer while in play mode?
I'll add that to the list.
Awesome!
Hmmm. Could you make a short audio recording of what you mean as we have no way of testing the win version.
This is great! Thank you, guys!
Wow. So, I've just had a play around with the help file. This critter is seriously powerful, as expected. And thanks for doing a "kitchen sink" patch. That's the one I'll be duping.
A couple of techie questions:
1) I'm also in love with the passed-zero reverse while recording bit. So bloody useful, too. Any idea on how to patch around the fact, that once I switch out of this overdubbing and into play mode the playhead resets? I can't quite wrap my head around that - pun intended.
2) If you'd humor me here: how do I sync karma~ to my systems internal clock? Like, I'm thinking I'd just make sure that it gets the appropriate pos. message every quarternote, but I'd love to hear suggestions on a more precise method :)
Glad you dip it. The kitchen sink was a late addition to the help file, and was primarily put in for testing/debugging. But yeah, useful bit.
1) Not sure what you mean. Ending any initial loop (via play/stop/record) will reset the playhead to the start of the loop, and going in/out of any overdubbing will leave the play(/record) head where it left off. Oh I get it, you DON'T want it do reset the playhead.
In that case you can keep track of the current position (via the outlet) and then when you stop recording/overdubbing you send that as a 'jump' position. You'll have to multiply that by the total loop length as the outlet presumes the full loop length when making a new initial loop, but your actual loop will be smaller than that. I can cobble something together if you explain what you mean/want more clearly.
2) Sync wasn't a big priority of design, even to the point that there's no signal/phase output (ala groove). It was a choice between having a robust list (as a max message), a groove-like sync output, or having it be redundant. If that's a big enough issue for people (not having signal rate sync) we can revisit that. As far as the tempo/clock-specific stuff, it wasn't even really considered. Are you just thinking/wanting to use this ins a tempo synced environment with other playback objects?
1) yeah it's not really high priority for me, I was just curious. Kind of drunk-walking around inside an audiofile and overdubbing as you go is pretty fantastic.
2) I'm totally down with the philosophy of the build. I get it. BUT I'm a sync-freak, and I'm all about having tons of stuff over a network working in concert. Just wondering how you'd approach it personally. I guess I'm asking about best practices.
I don't need signal-rate sync. In fact, it might be cooler to not do that, in some way. But I'll definitely need to build sync. Let's imagine I'm doing a four-bar loop, I'd at least want to sync rec start and end. I guess this would be a bit too idiosyncratic for you to support, seeing as everyone does their timing differently.
I'm interested in sync as well. I hope to get this into a patch that I have that displays loops as groups of 8, 16 buttons, indicating play position is important to me. But I suppose I can figure something else out, in fact, it might be fun.
Managed to crash it by wildly scrubbing varispeed across zero. FYI. :)
This is maybe a very dumb question, but how can I change the length of the recording/loop/buffer?
os
@Wett & @Evan
The outlet does allow for sync, and you can adjust the report rate on it (defaults to 50ms). You can use that like you would the sync outlet of groove, it's just not signal rate. Attached is a bit of patch that shows you how to control output leds (ala monome/launchpad).
Best practice would be to have multiple playback objects being driven via a master phasor. Not really possible here since you only have Max messages controlling start/stopping. If you're timed to something else you can just start 'record' at the start of the loop, then 'play' at the end. What would you be syncing TO?
@Wett (crash)
Do you have a crash report? Or can you reproduce it? Which version were you using? (what did it say in the Max window?)
@OS
There's multiple levels here. For what you want, I would imagine 'window' would be the best control. But there's the top level buffer (the WHOLE buffer). This isn't used unless you create a really long loop. Then there's what's defined by creating an initial loop (hitting record, then play/stop). That's the part of the buffer that the rest of the object refers to from that point on (unless you append to it). And finally you have the 'window' which is a smaller subset of that initial loop.
argh fuck, forgot the crash log. I'll see if I can't reproduce.
I would be syncing to our own sync protocol, built around what's essentially the ticks coming out of [transport]. Basically 480ppq, straight up. We then have client abstractions that scrub around, do swing and all sorts of weirdness. If I could get it even in the ballpark of syncing to this system (dawn) it'd be the best thing ever.
Hmm, I've not messed around with that, but if you post a patch of something like what you mean, I can take a look.
That'd be great. Attached is the beta version of our clock. Essentially, send it a 1 and it'll spew ticks over the internet.
So, either something that'll sync to that, or something that'll sync to straight, you know, 0-15 counts, for instance.
Ah shit, I should've done my homework. 50 ms reporting will probably be good enough for my LED purposes. I'll try to find some time this weekend to put it through it's paces and maybe use it to make some sounds/videos for sharing.
@Wett
If I understand you right all you need to do is sync the start of stuff, and as long as you re-sync that every time it wraps around you should be fine. So whenever you receive the first tick/count, trigger karma events (either record or play/stop) then have play (or whatever the current state is) retriggered on the first time again.
@Evan
For all my monome stuff I use a 20ms refresh rate (snapshop~ 20) off of groove sync.
yeah, I basically only need to trigger "play" for instance, and it'll sync right back up. In fact, I could chop up this process, and send 0., 0.25 etc.
Yeah you could do that but then you would probably create discontinuities at each 'step' since you're sending Max messages, it's very very unlikely that it would happen with sample accuracy. The start of the loop is ok as there's generally a little imperfection there anyways, so it's not noticeable.
Cool. Will experiment further!
@Rodrigo Maybe tomorrow I can make myself a "time"
But I relaxed in my setup works well.
There is some aliasing zipper and sometimes some clicks at points where there are usually clicks but everything is tolerable. (and not too different from what I remember from iPoke ...)
Thank you very much for sharing the code.
I hope that works for Brendan ..
The only iPoke code is for the interpolation while recording. Playback shouldn't click or do anything at all, so that'd be something else going on.
Record a few seconds, let's call one measure.
Then move a little varispeed while doing overdub (some little zipper noise can be added to the sound in the more aliasing ratio zones (not .5 2. etc).
Then for example before reaching the end of the loop play a tone/continuous sound that is held above the loop point. (one syncope).
But again maybe I'm picky and demanding that ... but very cute create textures and that the loop does not "alert every time he returns"
Sometimes there is a click at the end (at looppoint). I do not know if this is click/impulse, non-linearity/interruption etc but there is a click.
Something beautiful loopers either EDP, JamMan, Mobius, SL is that it does not happen..
That definitely sound like some issues happening as there's none of that in the current mac version. I'm not sure how visualstudio works, but were there any compile errors or anything?
Vs2010 all ok...
Rodrigo does not have one in n times some clicking the loop point when you do overdub with live audio (sustained sounds)?
When you do overdub while varispeed.. not get some degradation parasitic type aliasing (zipper noise) a lower volume level course?
Anyway, perhaps ...
if the system of interpolation (linear) is the same iPoke why in terms of aliasing would sound better than iPoke?
Okay, forget the clicks maybe I'm too obsessive, bad input levels ..
or I sit too close to the monitors.
But the zipper noise I do not think it changes or absent in Mac ..
I'll post an audio file later (at work at the moment), but I can do overdub/varispeed and no zipper sounds at all. At really slow record speeds you lose high frequency content, but that's unavoidable.
A big difference with ipoke is that this does playback and record interpolation. iPoke is just a record object and does linear interpolation for record. Not to mention this handles all the declicking/windowing for jumping around and loop point/edges.
Here's a quick audio file done with the built-in laptop mic, doing varispeed while recording, and additional varispeed while overdubbing, then just recorded via sfrecord. There might be a click at the start of the sfrecrd bit, but I let the whole thing loop around.
@Rodrigo
Please do not confuse the sound of the strings (ground ) with the click passing on the looppoint .
https://soundcloud.com/cassatopo/rec-karma
Nice licks, Wendy
Ah right. You're referring to specifically holding sustained sounds WHILE overdubbing? (and the start/end of that)
@Mike S TX :) licks4clicks
@Rodrigo Yes..That I was trying to say Rodrigo.
I can confirm that bug on osx. Also, the input selection module makes my audio bug out, but I think that's more of a max7.0.1 thing.
Ok, I can confirm this. I hadn't ever noticed that.
So to be clear, what's happening is that WHILE creating the overdub, a click is heard, but once it's looping, there's not a click anymore.
I'll pass this along to raja.
@Barbara
Thanks for finding that! So that's the only issue you found with the windows compile? If so that's very promising as that can get fixed for the next beta update and it should be working a-ok in windows too.
Yes, it is the only bug ( "for now" not optional feature) I found ..
I saw that there is a "to do" Raja , on other types of interpolation..
Yeah, the main things for the next version (which will likely be 1.0, and release ready) will be the couple of bug fixes found (including this clicking), changing the buffer swap message (from bufr to set), branching the stereo 'ifs' into their own function (for efficiency).
Eventually we want to put better than linear interpolation for the recording (the current ipoke code) as well as better than linear interpolation for playback. Both will require a bit of research/work, so that will likely be a 1.1 down the road a bit.
Hey Raja n Rodrigo
great work !!! since I'm such a looped-away fella as well,I did a little thingy
that can do sync recording.(but none of the other cool stuff yours does)
it's attached to this post.. gen~ and max7 but should work with max6 ...
I also got some more ideas about looping . if you want to get in touch contact
me off the forums : rbrt_devices@gmx.net
I didn't read all posts in depth,two things got stuck anyway:
-about the clicks at loop-end: you might try to set the recording-head to the very end of the buffer once recording is done.if it stays at looppoint, the input signal might 'leak through'
-if you record values to a buffer above or below 1/-1 , max will play back the buffer correctly,but when you write the file to disk,it will be cropped and sound really bad or good.so you have to normalize the buffer.
cheers , rbrt
Any reason you think it may be crashing max for me? Looks very useful, can't wait to try it out! Running Max 6.1.9 32 bit, got it in my Cycling 74' folder where it belongs.
Thanks
When is it crashing? On load? While doing something?
Are you using the (b) version of it?
wonderful! thanks for your work and when everything will be ready to test on Windoews please don't forget to compile for Win64!
@Alfonso
Barbara posted a compile of the windows version earlier in the thread if you want to have a play with that for now.
@RODRIGO Great but, it seems that is Win32 only. I'm on Max7 64 bit.
Ah right. Well that will come at some point too, but if you want to test/use it now, just use in Max7 32bit mode. (I'm still on 32bit myself since not all the externals I use have gone 64bit yet).
Awesome! looking forward to it.
THANK YOU so much Rodrigo (and team)!!! This is really awesome and makes me super happy! This object is 99% of what i ever wanted to do with Max in the first place.(became a lot more btw) I never figured it out with only Max objects though. (due to time and limited knowledge i guess)
The other 1% btw is some sort of undo/redo function. I guess i can solve this with some sort of buffer~ copy method.
I have one question: is there a way to do a instant reset / clear of the karma~ object so that it clears the associated buffer~ and you can start a new loop with different length?
Mark
@Mark
Undo/redo is something we talked about at the start of the project but that's a maaaaasssive can of worms, so it was left aside and will likely stay that way. Too big a fight to pick with everything else the object does. That being said, can probably figure something out using polybuffers and buffer copying (so each overdub is a new polybuffer instance and you copy the contents of the previous one over to the new one).
As far as the second question, totally. You just hit "record" while in a stopped state. It clears the existing buffer and starts recording from scratch again. The initial buffer size serves as the "maximum" loop time. Each time you make a loop it plays and uses that part of the buffer only. The "whole buffer" is still, just sitting unused. So when you start a new "initial loop" you start recording into the "whole buffer" (you can see the waveform display change to reflect this) and when you hit play (or stop) to end the recording, you've defined the loop points.
Hope that answers the question as I could have misread what you meant.
Rodrigo/ Raja - thanks for sharing this, it looks remarkably powerful and well executed.
@Rodrigo Thx! That's excactly what i meant and makes perfect sense too. I think it's a very nifty solution to have this kind of relation between the buffer~ object and the karma~ object. They really complement each other. I soon as i have some time i'll look into a buffer/polybuffer way of doing undo/redo.
Thanx again for this amazing object! You guys sure earned a lot of Karma points on this one! :-))
Mark
Thanks a lot for this guys. It reminds me of the first thing I built in Max (v2?) only yours is much much better! The only thing really different was that in my old patch the play speed varied separately from the record speed (I don't think one could change record speed back then) which occasionally led to some really insane sounds. Lots of clicks though, as the record and playback heads passed. I decided that that was a feature of the sound (hahaha).
@Rodrigo
have you considered adding an insert point to the overdub? So that one could add an external process (eg distortion, filtering...) to the feedback path.
@David
We had it run that way in a very early version but abandoned it for simplicity. You can achieve the results by setting 'overdub 0' and using send~/receive~ to re-record the output back in (but going through processing first). I think that would move it over by one vector each time you do it (due to how send~/receive~ work) so after a long period of time it might produce an issue.
OK, thanks. I'll give that a try and see what happens!
Ok, here's the 1.0 release ready version. Not doing a full on release until the tutorial vid is ready, but this is it for the code. The helpfile also has a full on reference doc on the final tab too.
As a reminder, there are 2 versions of the external included (along with the help file). The (b) version is the 32/64bit version that will run in either version of Max (6 or 7, or 32 or 64). The non-b version is a purely 64bit external. The features in both are the same, it just has to do with how things are calculated internally.
Enjoy!
Thanks Rodrigo!
it works very good. No more clicks. The sound is fantastic.
1) Any idea for multiply function?
2) Any idea for undo function?
Thanks once more for a great work. I'm a looper fanatic and now a new world of looping possibilities inside max begins!
Emilio
@Emilio
Yeah, we (raja) spent a long long time getting all the clicks out. Probably had like 12+ iterations between the last one we posted and this one.
Undo is quite attractive but that would require a complete restructuring. It's probably possible to do that outside the object using polybuffer or something like that though (using each buffer as the previous buffer + new material, then you just load older buffers for each 'undo' step).
As far as multiply. That kind of advanced stuff will probably be left out, at least for a long time, as there's other things that do all that better (sooperlooper etc...). It is a cool/handy feature, but it would require so many additional considerations/modes that even just thinking about it makes my head hurt.
I used to own an Oberheim Echoplex back in the day, and the manual was so dense, particularly when it came to this kind of stuff (multiply, replace, etc...). Like what happens if you end a multiply halfway through a playback, does it carry on recording until the end of that whole multiply, or does it stop and define the loop point there (ie 2.5 loop length) etc...
Thanks Rodrigo
I understand - I'm using sometimes sooperlooper through Ableton but in live situation I cannot trust. Something goes wrong very often (mostly because incorrect understanding of midi bindings).
So I prefer using my max4live patches - I'll work on your external to find some answers to my live questions...
best
Emilio
@ Barbara
many thanks for the Win version, looping away madly right now.
Brendan
@Barbara
If you have a spare moment, it would be super super helpful if you could compile the (b) version of this so people can have a win32 version. (For now, until we figure out a more permanent solution for compiling windows builds in the future).
@Rodrigo
Lately I 'm short on time , anyway, hopefully I can fix , link , definition , header nonexistent, and finally compile.
As was the case v0.98
But there are now hundreds of syntax errors!!!!! (encode?)
Especially where it is called a new interpolation function .
Thanks for trying!
Did you try to compile the (b) version or the other one? I'm thinking it might be trying to compile the 64bit one, which could potentially be defining variables in ways that don't exist(?).
Hi Rodrigo
in a polybuffer contest the message "set " tells karma~ which buffer~ to use?
It's about my studies about the possibility of undo function...
ciao
emilio
@Brendan
etc..
Please someone can tell me if it was useful, or had a problem with the version 1.0 compiled for Win, which I upload here a few days ago .
Thanks...
@emilio
Here's how it works with polybuffer
@barbara
I wish I could test, but no access to a windows machine.
Rodrigo, Raja - HUGE thanks for creating this amazing looper! Barbara - thanks for making a Windows version.
I have been playing with the 32 bit version in Max 7 on my Windows 8 PC and not experienced any problems as yet. It is great to finally be able to move through a buffer without getting clicks! Fantastic record/playback options too.
Cheers!
Paul
No problem!
And glad to hear the windows version is working a-ok! Thanks again Barbara!
Nice work!
thanks!
@Barbara Cassatopo thanks for the Win version.
Any chance to get it for Win 64?
I know there are issue with compiling on Win 64 bit with MinGW and the likes but maybe you're on VS?
thanks and all the best
PS : anyone knows how to properly tag people on this forum?
Yeah, if Barbara has a 32bit project i can try To convert it to 64bit. I have to say that my other attempts to do similar things with CodeBlocks/MinGW always failed. I had succeded with VisualStudio. (except a big fail trying to compile csound~ for Win64)
@Barbara Cassatopo
Hi Barbara, wouldn't you mind to post your karma~ Win project file? I'd help to to try a 64x compile.
Thanks and bests
Correct me if i'm wrong, but i can't use karma for sample playback in combination with standard buffer operation.
Since you can only load an audio file into the buffer once & that's it. If i try to load another file into the buffer i get the following message: can't read file now. Clearing the buffer doesn't help. The same goes for the crop message send to buffer, i get the following error: can't resize now.
Is this working as intended? & if so, are you thinking about changing karma so that it can be used for audiofile playback?
You can load new buffers and load/replace buffers, but you can't crop or do things like that. You can achieve the same result using position/window controls. Because of how things are declicked/handled, it's not meant to control/edit outside the context of the object and it's controls.