Ableton Forum

Hi,
i am using a lot of random follow actions, mainly on rhythms. As it takes too much place on my launchpads and f**ks up the scenes above, i had the idea to create a patch to fake them and constrain to have the process contained in one clip. It would change my life on stage.
the idea is to use the message "call move_playing_pos" in a long clip actually made of several clips (acting horizontally instead of vertically in the session view).

anyway here is my first attempt, it kind of works, but i am not very familiar with timing in max and it's buggy. I am concerned about the accuracy i can manage to have. Help would be very welcome. (now just on 1st clip 1st track, 4bars)

louis

<pre><code>
----------begin_max5_patcher----------
747.3ocyXtsbaBCDF9Z7SgFldUqqGj3joW01WiNYXjAkD0JjXPxoIMSd2qNf
SbN.lDqgga.qUBzu97tqVw8qBB2ItkHCAeC7KPPv8qBBrlLFB5aGD1fushgk
1gExI+Ur62gqccoH2prlqIL7c.XF+POWJ3JI8eDSuvnMQ8l46anbFQYeYndi
sXU00T9UkcjJkSLnsw5mA.SJL2RyrM1tIBbQ+yPqsyqVKeEc7bxwM14L7GcT
LC7SAqN7o4VrWcXxg8VclT20Rbyb3NL+pPvEldeX0Jyk0mGajDFHwWboHxhB
nEOwwiwk33ODXPiBl0fPuBmFhpSXbb.eGWon2PfdhTwPjEQPKhhRGiTvjEtK
jpCykshNkegiKtBcB37gXSwPrgxUFmn9aWxD3A9waMJuBU8Ks14SOclBGloF
9sFXujNJPS2tv81LfogHk.nmPCJ1hkbykrhQYSteYiW4xm8WZbXhgBEVrDi1
jNBQx7KQLgT9DJeA.8KTxyNMTRxW1PQmttVz3a2kz7SWLTBZgPFSBD7UjWgl
JLiAZD2PJa0kLZVmsBI3S9xIB5niKYLL1xMis2r.ohEbxFltVnM5NLqLuhFW
t3Lzn64i7NY56RhugTW5VWkXkpitauxcDjfGATPXYKoSRkJBuxsbs1sj0WkT
A1AX9ZqeafYtcW+zsik3BBWR0jOTLpdIdMv3.VJIJft3yp+HAQfJFssTxDpC
M7kiYdeFeqGYwXgrvnkdHqgcd0sJ0cHOWx+AS6+gvR7fXou96miG6DqWk7W9
ICrZ2X+4LSJ12Uc3U1eRcvSxulHUTNVQE7iFSxyGz0z5Zhs+CzqgV2JzaK0q
gA9CbpRxbH4Spo4URlyGbRIYBDlSMkMAMY1O88nIDJ1lqTGrqugRerwYJVS0
gmTruXEMUwVXU4QMNWsNoXh74MlnXJNfyaPgYiS.bJZBNaZJYJXBNuXJZJtS
yqjlDll2rYSIAAblwzD7uewlUuOIoa7vp+yxYvXZ
-----------end_max5_patcher-----------
</code></pre>

It seems like a good idea, but the implementation is highly problematic due to inaccurate timing (delay) of the Live API.

Anyway, here are some comments about your patch.

1. Keep in mind that the value of move_playing_position is relative to the current position. So you need positive and negative values.

2. Since you are polling the transport with 16n, each beat selection [sel 4] will send 4 bangs instead of 1.

3. To compensate for the API delay, the trigger should be sent in advance by "some" milliseconds.

So you may continue experimenting a bit but don't expect great results.

Hey thank you broc !

1. Keep in mind that the value of move_playing_position is relative to the current position. So you need positive and negative values.
i am not sure... it seems that it keeps in the range of the clip length, doesn't it ?

2. Since you are polling the transport with 16n, each beat selection [sel 4] will send 4 bangs instead of 1.
i told you i wasn't so familiar with the timing.... i noticed that, the result is the same though. I'll correct it.

3. To compensate for the API delay, the trigger should be sent in advance by "some" milliseconds.
That what i was afraid of...i think i could be cool for audio, but may be critical in midi clips, where it could lead to miss notes. As it should be mainly for drumracks....

Anyway, do you have an idea why it switches to the "next" bar one 16th note before the end of the bar ? i didn't find a solution. Just tried to correct it in an experimental way (as i am not familiar yet with the way note lengths are expressed in the anglo saxon way).

(as a side note :
although i am a poor programmer, almost everything i tried to do appears to be impossible with the API....
i must be damned, but the 2 or 3 idea which would have improved my liveset workflow are undoable...)

chapelier fou wrote:Anyway, do you have an idea why it switches to the "next" bar one 16th note before the end of the bar ?

For exact sync with Live's transport you may need the quantize attribute, eg. [metro 4n @quantize 4n @active 1].

ha ! thank you.
i remember once reading something in max documentation about the metric timing system, but i didn't find it anymore...