move_playing_pos retriggers clip
I and couple of collaborators are working on a patch to allow monome users to chop up Live clips with M4L similar to the MLR monome patch. Current progress and the latest revisions are all in this monome forum thread:
So far the patch is working quite well, but I've noticed a quirk that I was hoping to get some official comment on. The patch uses move_playing_pos to set the playing position of a clip in response to monome button presses, which works great. Oddly though, 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.
The question is, is this a M4L bug, or intended behavior? And if it's the later, what is the reasoning for retriggering a clip when the playing position is changed?
Thanks for any help you can offer!
P.S. I'll also email this to Cycling 74 support.
I've noticed a similar effect when observing Live's transport. If playback is started while transport is not at start position, the observer sends the values 1 0 1. Normally it doesn't matter but in special configurations this may lead to unexpected results.
Sending the momentary 0 is probably caused by some internal reset operation, but I think it should be hidden from the outside world. So please report back if you get a comment from support.
Please don't cross post to support. The same people who read support email also read the forum. If I have to choose which place to conduct a conversation about something, I choose in public, so it might benefit others. Support is all about people who have problems getting the software to work right. Is this one of those type of problems? I'm not actually sure. Perhaps a patch demonstrating the issue would help us.
-A
Apologies for the message to support- I did mention this thread at the top of the email, so hopefully that saved some time.
Anyway, the patch in question is "live_clip_chopper_myr_r17" attached to the first post (from user "Myralfur") on page three of this thread:
If you have a look at the observed playing position in the [live_clip_v3] subpatch you should see what I'm talking about.
Thanks for your help!
Sorry guys, I have no idea how to reproduce what you're talking about.
May I please have a small patch which isolates the issue, with written steps for me to follow.
I don't have a monome handy, sad to say.
-A
ok
This is what I needed
It does seem that the clip gets re-triggered when you call move_playing_pos.
If this is not something you're mad about, then you should be able to workaround it - just ignore the output from live.observer when you are calling the move. Getting notifications for clip triggering when changing playing position makes sense to me in the general sense. There's no way I would consider this a bug.
Sorry for being pedantic about your reporting skills, but we're really busy right now,the more you can do to make issues clear to us, the faster we can get to them.
-A
Hi Andrew,
No worries on being pedantic- I'm a software engineer myself, so I understand the difficulty of bug reports without accessible examples of the problem.
I agree with you that notifications of clip triggering are probably OK when changing playing position, however; the big problem here is that the observed playing position of the clip jumps to zero momentarily whenever the position is changed. Here's a simple addition to your example to help illustrate:
If the issue isn't isolated to my machine, 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.
Thanks again for all your help!
I just realized that I framed the original question as being isolated to clip re-triggering- sorry for the double confusion there, I think I was doing some sort of self-diagnosis (playing_position discontinuity + clip retriggering -> clip retriggering must be the problem) in an effort to be helpful. Hopefully my last post is more helpful and direct.
Maybe for now you could select out the discontinuity and then re-patch it somehow so that your step counter still displays correctly.
This seems to filter out the discontinuity for me. I'll ask the Ableton guys about why it's there in the first place
Andrew: Just wondering if there'd been any word from Ableton on this. Thanks!
Hi,
I'm not a coder and allready don't know how to. But I'm a user of this pacth, Live Clip Chopper. And in fact with this playing position problem, LCC is useless. What a shame for me, it's one of the reason I get a monome: beeing able to control clips into ableton as mlr.
I would be awesome if one day it will function!
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...
i came across the same problem in another variation.
i use a clip playing position observer to display the playing pos of a clip.
and if a loop is set in arrangement view! and it jumps to 0,
the clip playing pos is also jumping to 0 for a short time.
you can see that on the scope Andrew Pask was using some posts above.
and a "select out the discontinuity" solution doesn't work in this case because restarts will also jump to 0 at any time.
cheers