karma~ (sampler/looper external) beta
All Mac users expect, publish VIMEO, for those of us pathetic losers of Windows?
sad to hear that. Hope y'oure alright
Yikes! Rough year man. Hoping for a quick recovery.
Reviving some old discussion here, re: sync.
I'm working on a similarly DL-4-inspired looper project, but one of the features that's important to me is access to the overdubs as individual buffers. In order to do this with karma~, it seems like I would need to figure out how to get some kind of sample-accurate sync. My non-karma~ approach is to use a phasor~ and multiple wave~ objects, which @Rodrigo, you alluded to, but looking at the help file, and the driving sig~ object, it seems like the phasor~ approach isn't possible with the karma~ object in its current form?
It's probably even more madness to think of this, but would recording overdubs to a polybuffer~ make any kind of sense? (I also didn't know about that object before, so even if I stick with the wave~ approach, it should be helpful :)
And in case I didn't mention it here or on llllllllllll, this is really, really spectacular work, both conceptually, and implementation, so many thanks, and many kudos to you both :)
I don't have any particular advice to your problem, I am just a little confused by your statement "access overdubs as individual buffers". Does this mean you want to access the recordings you make by using the overdub functionality of karma~? Or when you say overdubbing, you simply mean recording into a different buffer? Just a bit in the dark as to what your end game is here, and why karma~ is even the proper solution? Seems you're moving in a different direction. Please correct me if I am misunderstanding!
You can probably setup something using polybuffer~ but the having "each overdub as a separate thing" is a fundamentally different approach than taken here. In the early planning stages there was the idea of having a built in 'undo' feature (which would be kind of similar to that), but it was scrapped.
Same goes for (sample accurate) sync. Because of the play/stop/record nature of the transport, that's not sample accurate.
raja is working on a sampling kit that will more easily allow stuff like what you're talking about (sync is important to what he does and how he works).
And thanks for the kind words! Was really fun working with raja on it, even when we were knee deep in bug reports back and forth. He coded the shit out of that thing!
I'm glad people have found it as useful as I have!
I’m glad people have found it as useful as I have!
It's the backbone of my improv rig right now, and makes an appearance in pretty much all of my computer music performance.
@RKN: in gen~, poke can do overdub record. Also, now that you can have more than four channels in buffer~, if you went for the multi-record approach, you can do a lot more of them while being able to switch between them at signal rate.
To play back multiple layers, you could use a for-loop in gen~. While playback isn't as efficient, it would let you mute layers selectively, and you can also do fun things like advancing through the different channels at independent rates. (basically using a buffer to store the playback phase for each channel via peek and poke--not ideal in terms of efficiency relative to C code but still surprisingly effective)
None of this to take away from this cool project from Raja and Rodrigo, just another interesting direction to explore.
Thanks for the replies.
@Evan, it's not clear to me that karma~ is the right object to use for my particular problem, which is part of why I was asking in the first place. To clarify, "overdub" isn't necessarily the right word in my context. What I meant was, at a high-level, I'd like to "overdub" onto an existing loop, but, as you said, this really just may mean recording another loop into another buffer, since I want to be able to access each take, sort of similar to how loop channels in Möbius .
I've been re-thinking my approaches a bit since posting, and it does seem that without the sync feature, there's not really a place for karma~ in this particular patch.
I still need to look into gen~, as I don't really understand how to use it. Using multiple channels of a buffer seems like a good idea if all of the overdub/takes are the same length, but gets tricky with half- or double- time takes, or allow deviation from the master phase via an offset (part of the idea here is that the buffer playback is synced but offset-able, to do mlr-style cutting).
You can still use multiple channels of a buffer even if they aren't the same length; the buffer just has to be longer than the longest recording length (but that's always true of buffer~, since you can't dynamically resize it). The key thing is that you can use different values to read different channels. If your rates and loop points are always integer multiples of each other, they'll be in sync, provided that any changes in rate happen at the appropriate boundaries. (you could also have a resync feature)
@ RKN : here's a little syncing looper I did some time ago.
https://cycling74.com/tools/syncing-looper/#.VpQ9-FlOJAI
I love this thing, nice work.
This may have already been answered, or I might be missing something in your help file.
This might be the dumbest question, but can you turn looping off? I'd love
to have the option of using it as a regular player where I can one shot a sample
when I want one without the looping.
Thanks again, awesome work.
It's more built around 'always looping' as you've noticed, but there's an example of how to do 'one shot' playback in the Misc tab of the help file (in the [basic_looper] subpatch).
It basically checks to see if the playback is near the edges (so it works while reverse too) and when the delta value goes above a certain amount it means it has wrapped around the edge, and triggers a 'stop' message. It's not sample accurate, but because of the declicking you don't hear any clicks and stuff at the end.
Is that in the helpfile or have you copy/pasted it into another patch? It should only show up that way if you don't have an accompanying buffer to go with it (e.g. [buffer~ transport 10000] ).
What happens if you delete karma~ and then undo the delete?
Or save/reopen Max?
just wanna make this . . .
. . . 230, must be some . . .
. . . kinda record, at least locally . . .
lol, it took me a bit to figure out what you were talking about.
Hi,
I am using one instance of karma~ to record, then have another wrapped in a poly~ for playback.
When I call an instance of the poly~, the encapsulated karma~ references the whole buffer (not just the part of the buffer with audio recorded).
Is there a way to reference just the part of the buffer populated with audio?
Hope this makes sense!
At the moment... no.
The way that it works is that when you record into a buffer, you define an "initial loop", which is what is referenced after that.
That being said, there has been a lot of activity on the karma~ github in the last few months and the ability to 'set' an arbitrary part of the buffer as an 'initial loop' is one of the new features (and lots of bugfixes).
(there will probably be a karma~ v1.5 mini-release at some point, on the forum(s), with a proper v2.0 launch with new videos/helpfile etc... at some point in the future)
Thanks for the quick reply!
I made a work round by recording directly into the poly~, sending it "target 0, record" and "target 0, stop" to set the initial loop on all the instance of the poly~ at the same time, then overdubbing/replacing on the 1st instance only, it's a bit crude but works (kind of!)
I will definitely check out the alternative versions on github you mentioned.
Great to see some activity on the karma side. Looking forward to new updates in the future.