I upgraded from Ardour 6 to Ardour 8. I keep hitting a very annoying GUI feature: a track ‘accidentally’ seems to get attached to the mouse in the editor and vertical mouse movement re-orders or resizes the track when I don’t want it. It is drag and dropping even though no mouse button is held down. This is unhelpful enough. But ‘dropping’ or otherwise stopping the effect is also problematic: pressing ESC does not decouple the mouse from what it is accidentally moving. Can I supress this behaviour some how? I am running on FC40 with Gnome. Many thanks.
That cannot happen without the mouse button being held down.
What version of Ardour, and where did you get it from?
I am using Ardour-8.6 compiled from source on 6.9.9-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 11 19:29:01 UTC 2024 x86_64 GNU/Linux
I had falsely assumed it was some sort of new feature in Ardour that you had introduced that does not work very well for me and which others may have encountered. But you don’t recognise the problem so it’s presumably a nasty quirk of my system with this version of Ardour. It could be as simple as the button up event getting lost, but it does persist over many fustrated button clicks trying to drop the blessed thing thats ‘stuck to the mouse cursor’. I think it’s worse after I’ve just renamed a track.
Sorry for the big gap in replying. I am now back in front of the problem. I’ll see if I can find out exactly what causes it: trying on another computer and with a different mouse etc…
DJG
I’m not sure if it’ll be the same for Ardour but something similar got reported recently by a Mixbus beta tester. It turned out to be a change to the preferences:- Preferences->Editor->Scroll and Zoom behaviours
I can’t see anything under the options you mention that might be relevant I’m afraid.
I’ve made a brief further study. The problem reliably starts after renaming a track by clicking on its name in the editor left-hand gully. After pressing return and the new name is adopted, there is a memory effect whereby each time the mouse cursor is hovering over the gully, the last-renamed track gets magneticly attracted and stuck to the mouse cursor. No mouse buttons are pressed. The mouse cursor is normally the 4-headed move cursor over the left-hand gulley, but it is now the default, NW arrow: the general arrow cursor. Whem moving the mouse outside the gulley, eg. to another window or the main waveform part of an editor track, the cursor changes to its appropriate shape (eg I-beam or finger link cursor) but it goes back to the system arrow cursor when over the gulley. It is there that the damage is done, with the last-selected track being shuffled in order and changed in width willy nilly. Making an edit in the editor window does not kill it. Saving the project or resizing the outer window does not kill it. The unwanted behaviour returns each time the mouse is over the editor gulley. Left-clicking in the gulley to select another track does select another track (highlights it) but does not kill the behaviour: the last renamed track remains being shuffled and resized undesirably.
Clearly the GUI system has state somewhere that I want to be reset. One thing that seems to restore normality is left-clicking on another track name to open the keyboard cursor widget for typing a new name but then pressing escape rather than return. This does not rename the other track, but does ‘drop’ the sticky track. Pressing escape a number of times in general can also terminate the behaviour, but seemingly a number of attempts are needed, typically with quite a lot of damage needing to be undone once one had regained control of the system. I need to find a key sequence for renaming a track that does not lead to the unwanted behaviour…
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.