move_playing_pos retriggers clip
|
Jan 11, 2010 at 9:42pm
move_playing_pos retriggers clipI 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: http://post.monome.org/comments.php?DiscussionID=6853&page=1 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. |
|
|
Jan 12, 2010 at 5:50pm
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. |
|
|
Jan 12, 2010 at 6:26pm
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 |
|
|
Jan 12, 2010 at 8:54pm
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: http://post.monome.org/comments.php?DiscussionID=6853&page=3 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! |
|
|
Jan 12, 2010 at 9:37pm
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 |
|
|
Jan 12, 2010 at 9:53pm
ok This is what I needed – Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
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 |
|
|
Jan 12, 2010 at 10:18pm
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: – Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
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! |
|
|
Jan 12, 2010 at 10:28pm
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. |
|
|
Jan 12, 2010 at 11:58pm
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 – Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
|
|
|
Feb 10, 2010 at 11:16pm
Andrew: Just wondering if there’d been any word from Ableton on this. Thanks! |
|
|
Jul 25, 2010 at 11:02am
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. |
|
|
Sep 3, 2010 at 8:13pm
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… |
|
|
Oct 8, 2010 at 12:24am
i came across the same problem in another variation. and a “select out the discontinuity” solution doesn’t work in this case because restarts will also jump to 0 at any time. |
You must be logged in to reply to this topic.