Ableton Forum

just a shot, but get loop start+ loop end or length for clip.

observed when it begins playing.

use various methods (phasor) to generate sync info.



the problem is making somethign that updates itself with the clip (recording a new clip and whatnot)

I tried something like this using the python api, the problem was the update frequency (100ms) wasnt tempo matched so youd get shifts in the trigger times.

This should be doable with m4l since all the metros can be synced very easily.
* monitor clip slots for new clips: has_clip observer (store length)
* monitor clips for playing status: is_playing, is_triggered observers (record current time)
* calculate where in the clip you are at the current moment

then technically you should be able to mlv type things with clips assuming you can actually nudge the playhead. There was a call in the pythonapi for this, not sure if its there in the m4l api yet.

Will try and put some test stuff together for this. Im kinda getting there with the javascript, easy to add listeners and the likes.

there is function.

have you seen Live Object Model? it is a refpage. delicious.

i'd like to +1 this request, as it would accommodate a clip-based mlr type instrument for the monome, extending mlr to midi loops as well as audio.

edit - also, since we can only jump a relative number of beats in a loop (rather than to an absolute point), observing playhead info makes life easier.

hi ST8! Nice to see you hear

keep us posted, I'm also interested. I've gotten this working with through the python api hack, same algorithm and same problem with the 100ms resolution. Don't have the time right now to dive into it, I'm still new to M4L

I'd like to +666 this request.

I've been working on mlr-esque functionality with clips. I've had partial success shifting loop points around in a clip, but it's messy. Getting a floating point playhead position in the clip so I could instead simply know how whether to positively or negatively sign a jump within the clip would be much more straightforward.

It has certainly been noted, as you might expect.

Gregory Taylor wrote: I'm not completely certain about this, but I would *think* that using the transport object might be smarter, since Max might be refreshed more regularly than the priority queue that updates stuff from the Live API. I could be wrong, but I don't think so.

yeah thats exactly right. we tried this a ton of different ways, transport was a little icky in b1 but its spot on now, reports very obediently, a quantized metro can poll it exactly down to the tick, all stays in time nicely.

I thought i'd solved this and then i realised i hadn't +1000 for a proper solution!

Cheers
D