[amo] Arrangement: clips get dropped in the wrong place

[cbit]

Often when working in the arrangement view, when i drag and drop a clip, it ends up in a place other than where i released the mouse. This happens when i move my mouse immediately _after_ having released the mouse button. Instead of dropping the clip at the position i released the button at, it get dropped at one of the locations i moved the mouse through afterwards.

To reproduce:
* Create two audio tracks in arrangement view.
* Add an audio clip to the lower track.
* Select and drag the clip to a new horizontal position, before releasing the LMB, position your cursor just beneath the horizontal boundary between the two tracks.
* Release the mouse button and move the mouse upwards immediately afterwards.
* The clip will often end up in the top track, instead of the bottom one.

(Although it's hard to be certain that you're releasing the LMB before or after moving the mouse, i'm convinced that this is a new bug because i never have this problem while working in Live 7 and earlier)

[Amaury]

Hi,

Which beta are you using? There's a bug we fixed in beta 21 that sounds similar to this. If not what you're using already, please try in beta 23.

Regards,
Amaury

[cbit]

Was using b22, but i just checked in b23 and the same problem persists.

[Amaury]

Hi,

I'm trying that and I'm not convinced there is a bug here. Indeed, it may happen the mouse moves before the mouse button is released, as the pointer is just at the border between the two tracks.

But if you are convinced something is wrong, let me know how I should look at things. Please first try the exact same thing in Live 7.

Regards,
Amaury

[cbit]

hello,

I just double checked in live 7.0.7 and I can't get this problem to happen in that version (whether during normal operation or by following the 'steps to reproduce' above).

But in the live8 b23 it happens about 50% of the time while i'm dragging clips as part of my normal workflow, and about 90% of the time if i follow the 'steps to reproduce' procedure. So i'm convinced something has changed for the worse here.

[Amaury]

Hi,

Again, just to make sure, where are you dropping the clip? just on the line separating two tracks? Do you have to move the mouse, at the time of the drop, or does it happen that you just drop and the clip ends up in the wrong place?

Regards,
Amaury

[cbit]

hi, thanks for investigating this.

The problem happens regardless of where i try to drop the clip; if i move my mouse too quickly after releasing the mouse button, the clip ends up in a different place than intended. This might be in a different horizontal position on the same track, or if i move the mouse vertically after releasing, the clip sometimes 'jumps' the track boundary and lands in a different track. To guarantee that the clip lands where i want it I currently have to deliberately wait for a moment after releasing the mouse--which is of course inconvenient.

Most often what happens is i'll drag a clip horizontally within the same track, drop it, and immediately move my mouse up to the transport controls to preview the new pattern (a movement that's become habitual). In the live8 beta's, many times this results in the clip 'landing' in the track above the original one--which never happened in previous versions.

I suppose it's possible that there has _always_ been a period after releasing the button in which post-release mouse movements would effect the landing position of the clip, but that in previous versions of Live this period was much shorter (fewer calculations being performed?) and so never presented a problem--this is pure speculation of course.

[Amaury]

Hi,

Are you using a Mac?

Regards,
Amaury

[cbit]

Yes I am. Sorry i forgot to add my machine specs to my sig. I updated it now.

[Amaury]

Yes I am. Sorry i forgot to add my machine specs to my sig. I updated it now.

All right. There an explanation, that you may not be too happy to hear right now, but I think that is what's happening. I'll try not to loose you.

In Live 8, for drag and drop operations, we use the standard OSX mechanism, which show this behaviour: when the machine is busy, which happens all the time, it queues mouse operations. Normally, after releasing the mouse, it should remember the location where the mouse was released, and do the drop operation there. There is currently a bug in OSX that makes the drop happen where the mouse is at the time the drop can happen, not anymore at the position where the mouse button was released. This is a bug acknowledged by Apple, and we can't do anything about it.

In Live 7, we used our own drag and drop mechanism, but the problem is that it would only work within Live, not allowing us to drag and drop files from Finder to VST plugins for example. There are other reasons we needed to use the Apple mechanism.

So, I can't give you a really happy answer right now, and I hope you understood my explanation.

Regards,
Amaury

[cbit]

Ah I see, thanks for finding this out. But I agree that it's not happy news!

I'm worried that this will mean I won't be able to work on complex arrangements in Live8 without a lot of frustration. Do you know if there's anything OSX users can do in the meantime to try to keep the event queue small? (eg. use fewer plugins? get more RAM?)

[Amaury]

Hi,

Well, there's not much, but having of course the fastest machine. Also, this may happen way less when the transport is not running.

I guess it's a matter of adapting the workflow for now, like, not moving the mouse too fast after dropping, and let's hope this gets fixed from the Apple side.

I'm moving the thread away for now as there is nothing we can do for the issue.

Regards,
Amaury