petition: tighten move playing position in M4L
Greetings. I’m an enthusiastic end user of the "live clip chopper" m4l patch which enables me to chop Live clips and replay the samples on my monome. The patch has grown by leaps and bounds since January. However, there has always been an intermittent timing issue between a monome button press and moving the clip playing position in Live.
The developer, nonagon, first described the problem in this forum thread:
"it appears that every call to move_playing_pos causes Live to re-trigger the clip. This isn’t noticeable in the audio stream while chopping, but it does cause the first LED on the monome to flash briefly whenever the playing position is changed. We can also see this in the playing position data, for example:
If the clip is playing back on a monome with 8 buttons in a row, clip playback will normally progress sequentially, lighting the buttons on the row in sequence:
0 1 2 3 4 5 6 7 …
If a button is pressed during playback, the playing position jumps to the associated with that button. For example, if button 2 is pressed partway through playback, the stream might look like this:
0 1 2 3 4 5 2 3 …
What we’re seeing though, is a momentary 0 in the stream:
0 1 2 3 4 5 0 2 3 …
which corresponds to the retriggering of the clip."
"big problem here is that the observed playing position of the clip jumps to zero momentarily whenever the position is changed…you should be able to see a discontinuity in playing position (jumping to zero) every time you set the playing position to a non-zero value."
I was wondering if we could follow-up this issue? I’ll also repost this in the Ableton forum since it sounds like this is related to Live’s core development rather than an integration problem with Max.
Cheers…and thanks for reading!
—Growing user base & New developments—
While I totally agree that we need better move_playing_position support, I used this method to keep my video’s from jumping to zero every-time the clip fired. Essentially if the play head reports 0 then it plays the last position before the zero. Like I said, it’s not perfect and may not be practical for audio clips, but it works for video well enough.
----------begin_max5_patcher---------- 594.3ocwWF0aaBCDG+YxmBKTeLCgc.BYSZRceM1plHvkDOA1HrSVxp528gOC MMsIsPxf8Rf67Ym+7i6Nadbhi6R4dP4R9L46DGmGm33ftLNbZrcbKR1mlmnv vbK.kJYM3N0NlF1qQ+LuX+3vvYsCrRJzJ9e.yfTeO+F2hsEbQNnwEiczobqt 0KswaYhNcCWr9mUPp1JwEKpWHBiwLWBMqJgF44SdnYJ1UQenDrw6597P7LTl xk+5SyhYuTkhjBLb26q3I4juIyybMi9zjIlel1QvHfeWu3ugK7Uj6VQIek36 Qza.AZA4JfTKVlwpcJ4bAjJ2Jv4EzCLROKFYWFigQFxEiTLJ.YI6co3zKQx4 yGORpfbh+smd8NbIB4BML1bY1LzH98.yxDw5KCmfgHM6+Z82blkIA2T8W3rE iHX78FTjDEhTHv+FQR7Hhju7ipzbdohn.MoPt6dMu.H2c9NQrAMgx1POzBQJ V+wl2+N5QiXG8b9NvStTAU6fpAseDEwRHVs0V5cc8oCBFwzqxJYIToOPJySN XdhJkJtlKECagns1ylI0z79JNaPPXOHEtBX4xqNCEpOi+SwmRtsJs8++4Vgj ihLCTZtHAg0wnvz6WD0FdVFfAzhtBdVojKzMxf7vYec1UUgP3iUkIopOpJZg WX89pX5LKn89aVqrNn0Wy4glfX+7NPvQ98p43ZD5Gxp3ShZ3y1B5BqPs2CVY yvlimkqdS5l6+mPvtks0CBZ0G0VZPo1lWmZY2ojRYXjFqQ5QIdjKb5TCQyWv c0on0FOM4uP6431w -----------end_max5_patcher-----------
(Please use ‘copy-compressed’ when posting patches)
thanks troy, i’ll cross-post to the monome forum ;-)
i worry that we are confounding two slightly separate issues here. The ‘jump to zero’ problem is one thing, but to me the larger issue is the inconsistent response to the move_playing_position call. It needs to be able to reference a specific clip location, rather than a relative ‘move x beats’ response. As it currently works, we need to observe the current playing position, figure out the difference between that position and where we want the clip position to be, then send a move_playing_position command from that. It just doesn’t seem to consistently produce a jump to the right place…this has nothing to do with the jump to zero effect, which is easily worked around. The inconsistency of the latter issue is a much bigger concern…
is it tight with midi now?