2 Years Later: Still no Jump to Absolute Clip Position API

[mastahlee]

I've been out of the Max 4 Live game for over a year now, but dusting off my performance patch for an upcoming show had me all riled up about this issue again. I know this was an issue a lot of people were vocal about when M4L was first released (myself included), and I was hoping with all the time that's elapsed the situation would have improved, but that doesn't appear to be the case.

What I'm talking about here is the ability to jump to any arbitrary absolute position within a currently playing clip. The ability to jump to beat 1, beat 5, beat 10.5 within a clip.

Honestly, the move_playing_pos function is a poor substitute for this API call. Except for some niche cases, who really cares about moving the playhead relative to the current position, but rather moving the playhead to an absolute position regardless of where it is currently? I think I've thrown every trick in the book at the problem of creating a true bufferless Live session clip chopping patch, so let me document my pain here:

First Attempt:
Try to use move_playing_pos function in conjunction with observing the current position, and then doing some relative beat arithmetic combined with a metronome trigger in a attempt to get the result be a whole number. As anyone else that's tried this has probably realized, you don't get consistent results. You can attempt to call move_playing_pos precisely on beat 3, subtract 2, and end up on beat 1, but depending on your latency you'll end up on beat 1.12034242, or 0.95315, or 1.203444, etc. You can try to compensate for the latency, but this approach is fundamentally flawed because the amount of latency is not consistent. I've put clips in retrigger loops to test the patch and always end up with something that dances ever-so-slightly around the beat you're aiming for. For kicks and snare retriggering which have very quick attacks, this ends up sounding terrible.

I believe this is the current approach of the Live Clip Chopper guys.

Second Attempt:
Putting the arrangement view in a 4 bar loop, creating a set of arrangement view cue points at set intervals, and binding them to keys and triggering the cue points to manipulate the arrangement clock. This actually works surprisingly well. The loop in the arrangement view doesn't affect the playback of session clips, but the triggering of the cue point moves the session clip playhead exactly like you'd want. There is one big flaw that keeps this from being viable, however: it globally affects all currently running session clips. This, of course, makes sense considering what its doing (manipulating the play clock), but sadly makes it nonviable as a method for chopping multiple running clips separate of each other.

Third Attempt:
I thought I was being particularly clever with the next approach, although it appears others have come up with it as well: move the start marker to the desired location and then instantly retrigger the clip. This works...ok. The problems with this approach are as follows:

1) Live compensates for movement of the start marker to ensure that the playhead keeps the same relative distance from it. So if you move the start marker to a position 2 beats later in a clip, the playhead will also instantly jump 2 beats forward. Move it to a position 8 beats earlier, the playhead jumps 8 beats back. Whether this is intentional or a product of how this data is internally represented I don't know, but to overcome this you have to trigger the start marker move as soon as possible before retriggering the clip, and still I've noticed certain jumps (beat 7.75 to beat 1 in particular) comes with a noticeable audio drop, even with the clips stored in RAM.

2) The API call to change the clip start marker position changes when the clip is looped to move the loop start marker. While I'm sure it seemed clever and efficient during the design of the API, it unfortunately runs afoul of this use case, leaving me unable to loop clips if I want to manipulate the start marker. Sure, I could quickly turn off looping for the clip, make the change, and then turn looping back on, but that leads to...

3) The Live anti-feedback system. When you start piling on the hacks, sooner or later you hit this restrictive little bugger. While undoubtedly necessary to keep us hackers from bringing Live to its knees, the accursed "Changes cannot be triggered by notifications" message is maddeningly restrictive. Ok, so I want to move the start marker, but first query the looped state, deactivate looping if enabled, move the start marker, then reactivate the loop. Whoops, you're making a decision based off a notification, so no dice. Even if you "deferlow" your logic like mad, it'll still pop up occasionally, causing a small percentage of actions to fail.


Fourth Attempt:
This is more an extension of the start marker manipulation, and is what I am currently using. In order to circumvent audio problems from moving the start marker on a playing clip and retriggering, I make a copy of the clip, and alternate firing between each clip. In concept, this is actually pretty similar to beat juggling on two decks with identical records. I "cue" the second clip by setting its start marker, then trigger it, cue the first clip's start marker, trigger it, ad infinitum. While the end result is the best sounding solution I've gotten, setting the start marker on a non-playing clip removes any audio issues and drops from manipulating the currently playing clip, the obvious issue of having to manage a second, identical copy of a clip (either creating it myself, or using keyboard macros since the Live API can't create and destroy clips currently) is a hassle and inefficient. Also, point 2) and 3) are still unresolved (although I've managed to work around them mostly by abandoning Live's loop feature and making loops through retriggering clips).

This ended up being a longer rant then I planned, but as you can see the road to absolute clip position manipulation has been a LONG one for me. I'm hoping this gets some attention from the Ableton crew (although I'm hoping they probably already have this feature on their roadmap). Anyone else figure out any better strategies? I'm going to take a look at the Live Clip Chopper code tonight, maybe they figure out something I didn't .

[Myralfur]

we didn't figure out anything magical i'm afraid.

clip chopper code uses the first method you've described and was originally done by two_masks on the monome forum. i just abstracted it out for multiple clips, added some more features and ui to make it releasable. the lower the audio buffer size the better it works, but yes, still a bit off sometimes. having to load clips to ram with the mouse also makes it unusable for live recorded loop chopping.

for a while i've been meaning to finish off some devices doing it in msp instead of with the live api: a sample bank device with a polybuffer~ object which saves all the samples you load with the set; a recorder device which you can drop onto different tracks to record into the polybuffer~; a player device with a transport linked phasor~ driven play~ object, which when dropped onto a track monitors the currently fired clip and triggers a sample you link to it by clip name or scene number. could also take midi so you can use midi clip sequencing to chop clips.

i've also got good results with chucker~. but it's not quite capable of mlr behavior. i think a phasor~ driven system using play~ or wave~ is the only way to do it accurately.

[ino-01]

ableton,
please give us the absolute clip-position in api.
...
...
...

thank you.

[mastahlee]

for a while i've been meaning to finish off some devices doing it in msp instead of with the live api: a sample bank device with a polybuffer~ object which saves all the samples you load with the set; a recorder device which you can drop onto different tracks to record into the polybuffer~; a player device with a transport linked phasor~ driven play~ object, which when dropped onto a track monitors the currently fired clip and triggers a sample you link to it by clip name or scene number. could also take midi so you can use midi clip sequencing to chop clips.

Interesting approach, and probably would work for a lot of people's use cases, but unfortunately is still bound by the limitations of buffered chopping which include some compromises I'd rather not make. When you take the audio out of Live and manipulate it within MSP instead, you lose a lot of the benefits of the Live environment, most importantly to me:

1) The loss of the beat grid. You're now working with a plain-vanilla waveform with no beat information. This doesn't seem like a big deal when you fill your buffer from beat-locked material, but the second you start messing with the tempo you hit right into this limitation. Buffer devices handle BPM changes poorly, creating audible clicks and dragging down performance as they adjust, or don't adjust at all and are now out of sync. One of the coolest tricks that one can do with session clip chopping is mess with a beat and gradually ramp the tempo up or down while transitioning into another track. When I've got it working it is one of the best ways to transition between tracks of significantly different tempos. This is something you can't do with buffered clip chopping (at least as far as I can tell).

2) The ability to jump to a beat on a clip that's in the "future". By that I mean the first time you play a clip, you can't jump to beat 3.5 in the clip when the playhead hasn't gone past beat 2: the buffer doesn't contain that audio yet. This doesn't matter much for looping samples, but it does if your use case is playing entire tracks. To handle entire tracks you generally have to keep a rolling buffer that stores, say, the most recent 4 bars of the track as it plays, which shows its limitations in the following example. Say I'm playing a track that's going into a buildup, a simple way to do a variation on the buildup is to beat-repeat beat 4 of the final bar before the drop, for the entirety of that bar. So you have a 4 bar buildup that goes bar 1:1-2-3-4, bar 2:1-2-3-4, bar 3:1-2-3-4, bar 4:4-4-4-4. This is impossible using a buffer model since beat 4 of bar 4 isn't available in the buffer at bar 4:beat 1 time, unless the entire track is pre-fetched into the buffer which is unfeasible (I don't think any MSP buffer objects can hold an entire 7 minute track?), or at the least undesirable.

While I feel the above reasons are adequate for not taking the buffered clip approach, for me personally there is also a philosophical issue: I shouldn't HAVE to manage independent buffers to do this. That is what Live session clips are FOR. They are audio buffers with awesome built in capabilities that benefit from 10 years of software development, why re-invent the wheel in MSP? I just see all this potential for them sitting there, locked up, and it drives me crazy that there doesn't appear to be any progress on this front. I have to imagine this is a trickier problem then it appears on the surface (who knows what the actual data model of session clips looks like beneath the surface), or the Ableton guys just aren't allocating any developer resources on this issue.

If its the latter, shit guys, give me an NDA to sign and read access to your source repo and I'll code up an interface myself.

[Myralfur]

well, it's important to remember you can program around the problems you've mentioned in msp, the same way ableton programmed the functionality into their live clips. but yes, i agree that it is reinventing the wheel in a sense. part of the reason i brought ableton was for the time-stretching, audio warping capabilities they've worked so hard on since ableton began; programming all of that into msp would be a lot of work. although possibly the new gen~ object in max 6 will allow for better time-stretching to be built into msp without having to delve into externals.

just to clarify what i meant by the buffered system: i wouldn't have any of the audio that i want to chop in live clips. it would all be stored in msp buffers from the get go (or you could record in with a record~ object). you'd simply use blank midi clips to launch certain samples, and you could launch at any point in the sample. i wasn't thinking of a repopulating buffer that records the last 4 bars continuously like chucker~.

1) in a msp buffer system i guess you'd be using a groove~ object instead of play~ to deal with tempo changes. although you'd then have to deal with whether you want the pitch to adjust with speed or not. program some phase vocoding to do the job maybe. haven't tried much tempo changing with a play~ based system, but surely it works as well as the program you write to do the job. as someone who's interested in getting away from ableton for some gigs and doing it all in max i might put a bit more time into working it out. haven't used it in years but i seem to remember mlr handling tempo changes while chopping beats, could be wrong though.

2) i only use short loops of 4 bars maximum for chopping most of the time, in ableton and msp. use a much simpler setup for djing, just two audio tracks, full songs as clips and two eqs. didn't realise many people used beat chopping for full track djing. the clip chopper patch also focuses on entire sample length not a section local to the playhead, or the last 4 bars. did you say you'd worked on that functionality with the live api? i'd be interested to see it and incorporate it into the next clip chopper release if so. i don't think there's a limit to the length of a sample you can load into a buffer~. just limited by available RAM. a bit of a ball-ache but i think you can load specific sections of an audio file to RAM in msp buffers. is this maybe what ableton does with long samples? only loads the sections around where the playhead is? if so you could build such a system in msp, although you'd probably need two buffers and to load into each one consecutively in advance so there's no timing slip or glitch when the sample is loaded to ram and then triggered.

it is odd that you can get the desired functionality with a mouse click, triggering any point in a clip by clicking above the sample, and not with the api yet. access in some way to this mouse click functionality would do the job. obviously i have no idea how the innards of ableton are programmed to do that and how hard it would be to allow access to that through the live api though.

with how amazing the max 6 beta has been so far i can definitely forgive them for being busy with working on that stuff instead .

[mastahlee]

just to clarify what i meant by the buffered system: i wouldn't have any of the audio that i want to chop in live clips. it would all be stored in msp buffers from the get go (or you could record in with a record~ object). you'd simply use blank midi clips to launch certain samples, and you could launch at any point in the sample. i wasn't thinking of a repopulating buffer that records the last 4 bars continuously like chucker~.

Yeah, I understand. That makes sense for short clips and building up sets from a compilation of loops but doesn't quite work for full-track DJing. That's how most people perform in Live so it certainly is a valid approach.

1) in a msp buffer system i guess you'd be using a groove~ object instead of play~ to deal with tempo changes. although you'd then have to deal with whether you want the pitch to adjust with speed or not. program some phase vocoding to do the job maybe.

This really is the crux of the problem. By going with buffers, I'd be abandoning all of Live's complex time-stretching algorithms to do it myself, with results that would undoubtably not sound as good nor be as efficient, as well as take away time that I could be using to code cooler stuff for problems that aren't already solved to my satisfaction.

as someone who's interested in getting away from ableton for some gigs and doing it all in max i might put a bit more time into working it out. haven't used it in years but i seem to remember mlr handling tempo changes while chopping beats, could be wrong though.

I think this speaks to our differences in approach. You seem to be interested in constructing a DJ interface entirely in Max. That's cool, certainly is up to the task and many people do that, but that's a different product. That's Max / MSP, not Max For Live. I like the Ableton workflow and platform, I just want to extend it in a manner that seems logical to me and don't want to throw out all the work they've done just to achieve it.

didn't realise many people used beat chopping for full track djing.

I don't think many do, but that would change if it was accessible and practical.

did you say you'd worked on that functionality with the live api? i'd be interested to see it and incorporate it into the next clip chopper release if so.

Yeah, I've got an entire platform I've built on top of Live to load in prepared tracks from the browser into Live column "decks" and be able to access any 4 bar loop within a given track and do clip chopping. I built this all when M4L first came out, got it ready for some shows, and was going to release it once I cleaned it up and fixed some of these issues but then I moved to Seattle for a job and it all went onto the back burner until now. The basic algorithm for the clip chopping is explained in my 3rd and 4th attempts. The code itself is tied into my greater DJ platform, so I'd rather release the whole thing rather than just that snippet which would probably just be baffling and obtuse in isolation.

Feel free to PM me if you'd like to go into the specifics, although I'm currently scrambling to get stuff prepared for a gig in November so I might defer going into all this until after that is done.

it is odd that you can get the desired functionality with a mouse click, triggering any point in a clip by clicking above the sample, and not with the api yet. access in some way to this mouse click functionality would do the job. obviously i have no idea how the innards of ableton are programmed to do that and how hard it would be to allow access to that through the live api though.

Very true, I'm definitely leaning towards my "no developer resources allocated to this task" explanation for why this isn't programmatically available rather than technical feasibility.

with how amazing the max 6 beta has been so far i can definitely forgive them for being busy with working on that stuff instead .

Haven't played with it, but wouldn't it be Cycling '74 that's busy working on that, not Ableton? Besides assuring there isn't any regressions going from Max 5 to Max 6 within the M4L environment, I'd assume the bulk of the Max 6 work is in Cycling '74's court. That does bring up an interesting point in my mind, though. Who owns the Live API? I'd assume Ableton, but given that Max 4 Live is the only "official" interface to that API, how much cross-coordination is necessary to surface any new API features? Perhaps this helps explain why there seems to have been no additional API functionality released in the last two years, unless they're bundling it all up in a paid major version upgrade.

[11olsen]

what's the difference between using live itself to create copies of a clip with offsetted startpoints and some follow actions and the MLR method?

[chapelier fou]

what's the difference between using live itself to create copies of a clip with offsetted startpoints and some follow actions and the MLR method?

I see at least one : losing lot of space in the session view.
see my post here : http://forum.ableton.com/viewtopic.php?f=35&t=170945

[mastahlee]

what's the difference between using live itself to create copies of a clip with offsetted startpoints and some follow actions and the MLR method?

In order to get the level of control you'd want from a clip chopper (a button mapped to at least each 1/8th note within a loop), you'd have to create a shitload of clips for full-length tracks. Now, you COULD make only, 16 of these clips and dynamically shift all of their start positions every 2 bars depending where you are in a track, which I tried once on a whim, and then you run into the "Cannot Make Changes from Notifications" wall by attempting to modify the parameters of multiple clips based on current track position.

So this would only be feasible for short loops, and even then there is a more efficient process: keep only 2 copies of a clip, and alternate fire between the two of them. This allows you to dynamically modify the loop start of the current non-playing clip prior to triggering it, removing all the audio glitch and timeout issues one runs into in moving the start marker on a currently playing clip.

[Myralfur]

what's the difference between using live itself to create copies of a clip with offsetted startpoints and some follow actions and the MLR method?

it's a long winded inflexible work around. what if mid song you wanted to have a "solo", change the quantization and start chopping a beat in smaller slices. you'd have to have another set of scenes of prepared clips. i used to do it before max 4 live; it made sets into a sprawling mess and takes way longer.

[11olsen]

ok it never came to my mind that one would want to do it with whole tracks instead with small loops.
is it retriggered then for example every bar at the next position or how do you wanna juggle and not
loose the timming of the track?

@masthali The 2 alternating clips method sounds good, but on the controller side u still use 8 or 16 buttons and a patch is managing the 2 clips, right?

[mastahlee]

The 2 alternating clips method sounds good, but on the controller side u still use 8 or 16 buttons and a patch is managing the 2 clips, right?

Correct, the fact there are two clips alternating is abstracted away from the interface.