Karma Looper - Overdub Behaviour
Hi, Can anyone offer any advise on how to achieve the below behaviour with the Karma plugin? I have tried to do this through javascript with no luck. I have two buttons and would like to act like a boss looper essentially as follows:
Record Button - Record>Overdub (also 'record' function)>Play. So it essentially toggles between 'record' and 'play' once the loop length has been set from the 2nd press.
Stop Button - Stop
I seem to have this working ok at the moment but I can't seem to get the record button to jump back to play mode once the stop has been pressed (like a boss looper) and then continue to toggle between 'play' and 'record'.
How can I go about getting this fucntionality out of Max?
you can combine functions into comma separated message.
example
stop, jump 0., record
play, overdub 1, record
check status messages at rightmost outlet.
or any other combination you want to achieve.
If karma~ can't do what you need, make own looping
using plain max objects.
As @Source Audio said, you can chain messages (though be wary, that sometimes that can be problematic due to vector size).
It's a bit tricky to understand exactly what you mean with your description, but you can manage a separate "state machine" by looking at the right-most outlet (7th value I believe is probably most relevant) and then changing the message you send accordingly.
What you do describe of going from stop directly into overdubbing is not a built-in "state", but you can go stop->play->record to "immediately" begin overdubbing.
Below is a patch that does this (and includes a handy abstraction for adding a single vector of delay when chaining messages together):
Thanks both for these suggestions, to clarify. If I use comma separated messages (e.g record, record (overdub), play) can I get this to send all 3 'states' via button press? So - 1st press - Record, 2nd press (record *overdub*) 3rd press - play?
Being able to track which 'state' its in inlcuding stopped would be helpful if possibe
Based on that how would I achieve a - if stop is pressed go to play state first in the chain? I've attached a flow chart to hopefully make more sense!
So you basically want to do something like this.
You can modify the [sel 0 1 2 3] to track the states you care about, and then change the compound messages on the right to do what you want in the given state you're in.
The "transport/logic" tab in the karma~ helpfile shows how the internal state machine works, so you just want to vary from that by sending comma-separated messages.
After few years passed I checked karma~ again.
That itered messages seem not to help if one wants to do all
loop functions, like start overdub after stop for example.
Vector size delay between play, record produce gap long enough to
make it unusable for sustaining sounds.
message jump 0. does nothing if loop is stopped.
without delay between play and record, recording (with or without overdub > 0)
might start from last stop position in loop.
One has to switch Audio Interrupt On to make it more reliable.
then - ramp time not only creates fade of set length,
but also offsets recording start in case of message : (in stopped state)
play, vector delay record (ramp 441 samps - 10 ms)
if instead triggered as :
record 500ms delay play
it works as expected.
Yeah it's definitely not perfect, and from the original design/idea it was more about making this kind of thing easier to use in general, without considering these kinds of applications.
The vector issue didn't pop up until having it be out a couple years, hence the abstraction/workaround.
There is a redesign in the works (well, backburner/slow) that would make things like that sample accurate (basically taking signal input to control state/functionality), if one wants to.
I think in the end it will be a few different objects. A classic all-in-one object, then separate ones for control and interpolation/playback, separate record if desired too (so you can have processes in the overdub loop etc...).
I remember while taking part in further development of original looper, which then ended as
oberheim echoplex, the most difficult thing was to try to serve everybody's wishes.
And there were quite few musicians and ideas/needs involved.
But some basic functions for looping must be well implemented,
like clickless and seemless recording and overdubbing of any kind of audio
material.
I switched to max based looping not long after Echoplex finally was born
and never looked at hardware loopers again.
Since I don't care about any stretching or pitch shifting,
xsample externals were best choice, together with
fast copying/mixing between buffers for undo stuff.
Hehe, similar here. I think I sold my (oberheim) Echoplex to partly fund my first mac laptop to get Max going and hadn't look back either.
With karma~ it's been more about enabling some of the quirkier side of things (varispeed while recording, etc...) as things like SooperLooper handle more "normal" crazy looping ala Echoplex and things. And then having some real simple use cases with the generic record/play/stop messages.
Thanks so much Rodrigo! I've modified the patch you sent with [sel 0 1 2 3] and works a charm!
Thanks again!