View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006647 | ardour | bugs | public | 2015-10-20 16:28 | 2020-04-19 20:17 |
| Reporter | don3 | Assigned To | don3 | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.3 | ||||
| Summary | 0006647: Dragged (fader) automation points move away from intended value when mouse button is released | ||||
| Description | Ardour version: 4.4.0, downloaded from Ardour site Fedora 21 + CCRMA extensions XFCE on VNC; current screen size 1280x1009 (but varies with physical display used) Edit > Preferences > GUI > GUI and Font scaling : Default Steps to reproduce: 1: Create a new session, or open one with one or more tracks. (Audio regions are optional.) 2: Put a mark at some arbitrary point in time. (Also optional, but makes issue more "obvious" by limiting one degree of freedom.) 3: Enable Fader Automation on a track or a bus. 4: Set Draw Mode. 5: Set Snap/Grid Mode/Units to Magnetic/Marks. 6: In the fader automation lane, click to create an automation point somewhere near the mark. 7: Drag the point horizontally to the mark, and vertically to 0.0 dB. Release mouse button. Expected result: Automation point stays at the value last shown, in this case at 0.0 dB. Actual result: Just after mouse button is released, automation point moves up or down by a random amount, typically 0.1 - 0.8 dB. Reproducible with a track-pad as well (clicking only after removing finger from pad, with desired value shown), so it isn't my unsteady hands. Seems the only way to hit the desired value is to edit the point. While this is a minor issue, it can be disrupting to work-flow. (Even more since it can be hard to grab the point again (probably depending on resolution and location) and since the edit pop-up doesn't necessarily appear near the mouse location any more - since 4.0ish.) I didn't see this with 4.1 or earlier; didn't test 4.2. | ||||
| Additional Information | In the past, there was an initial point at time=0 with value 0.0 dB, so that a first manually-created point set at 0.0 produced a horizontal line. Now the initial point seems to be the same as the newly-created point -- which is interesting... but the initial value is essentially random, because the point-creating click is sort of a shot in the dark. So now when I create the first point, I have to edit it _and_ scroll/zoom back to the start and edit the initial one as well. The new behaviour would be nice if I grab the entire line (after switching to Internel Edit or Grab mode) and pull it to the level I want -- I will see if I can modify my work-flow to take advantage of this. I guess it would be convenient if dragging the line had the same "affinity" for 0 dB that dragging points has, as it seems a lot of my first points happen to be 0. (There are some other ways I think this point/line dragging operation could be improved - like maybe user-defined affinity values, or learning previously-used values - but I'm getting way off-topic, sorry.) In addition, the issue reported in bug 0005758 now seems to be worse now: Sometimes I cannot drag automation points to -inf at all, even after letting go and re-dragging, so I have to edit those too. Also, at step 6 above (creating a new automation point), all tracks become selected. (In fact, in Grab mode, just clicking in an automation lane - no new point created - selects all buses and tracks.) Is this intential? | ||||
| Tags | No tags attached. | ||||
| related to | 0005758 | new | Fader automation point dragged to -inf does not always stay at -inf. |
|
|
This should be fixed in current git (fc8b03ee). Please test. Thanks |
|
|
Tested (quickly) on nightly 4.4.154. - I no longer see the value change after releasing the mouse/trackpad button. :-) - Right-click > Edit now pops up near the current cursor location, like old (< 4.0) behavior. :-) - I no longer see all the tracks getting selected when I click to create an automation point. :-) Also: - The initial (time=0) point created with the first manually-created point still matches the 'y' value of the initial click, which means it's essentially a random value that I will almost certainly have to change. But it's possible that this newish behavior helps someone's workflow... so perhaps it would be best to open a new bug report to discuss this. - The issue with dragging a point to -inf (bug 0005758) has changed, for the better I think. Now the value displayed as the point is dragged to the bottom edge of the lane is not -inf (it's something like -170), but after releasing it and hovering over it, it's actually at -inf. The good news there is that it doesn't seem to take multiple tries to get it to hit -inf now. - When dragging a point near 0 dB, I haven't seen -0.0 (as distinct from 0.0) show up. I hadn't mentioned this issue here before, and it hasn't always been easy to reproduce, so it may be premature to say it's fixed. Overall, excellent results! As I say, this was a quick test with an existing session. Hopefully this version is stable enough to use for real work, so I can give this more "exercise" over the next couple weeks. Thank you very much!! |
|
|
After thinking about the initial (time=0) point creation item above, the current behavior could be nice, if it weren't for the issue reported in bug 0005759. That is, since the click to create the initial automation point (at a "randomish" y value -- ie, wherever I clicked) also creates a point at time=0 of the same value, we get a horizontal line between them. If I could grab the line and move it to the value I want, it would eliminate the need to move both endpoints separately. Unfortunately, when I try to drag the line (after switching to Internal Edit or Grab mode; it doesn't work in Draw mode), the value displayed does not (usually?) match either endpoint, and when I release the mouse button, the values of the endpoints don't match the value displayed during the drag. Further, dragging points and lines "feels" (to me) more different than it should -- eg: - Hovering over a line displays a "+" cursor but no value (of course, not all lines are horizontal, so some special handling might be in order there), while dragging a line does show a value. - Dragging lines doesn't seem to have any affinity for 0 dB. I'll add a note to 0005759 as well, which might be a better fit for the line-dragging topic. |
|
|
If you think this bug is fixed, then close it and lets work on 5759. Its getting a bit confusing here. |
|
|
No problem, understood. Apologies for going off-topic, but I thought there might be a chance that the additional context could be useful for this one. I've seen a number of issues with automation editing, and I wasn't sure how many might be related in the code. I'd been waiting to test more extensively, but from what I saw in my quick testing yesterday, I'd say this bug report's issue is fixed. (I also wasn't sure what the protocol was for closing bug reports - ie, whether the reporter should do that - and until fairly recently I didn't even realize that reporters _could_ do it. :) So I'll go ahead and close this one... Thanks for working on it!! |
|
|
Issue looks fixed in limited testing on nightly build. |
|
|
Hm, I didn't intend to assign this bug to myself when I moved the state to resolved. Should've been assigned to nick_m, and he should get credit for fixing it. I guess this is the sort of thing I was wondering about, with protocol/process... |
|
|
Issue has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-10-20 16:28 | don3 | New Issue | |
| 2015-10-20 18:39 | x42 | Relationship added | related to 0005758 |
| 2015-10-27 15:48 | nick_m | Note Added: 0017530 | |
| 2015-10-28 16:02 | don3 | Note Added: 0017534 | |
| 2015-10-28 18:59 | don3 | Note Added: 0017535 | |
| 2015-10-29 17:06 | nick_m | Note Added: 0017540 | |
| 2015-10-29 17:21 | don3 | Note Added: 0017543 | |
| 2015-10-29 17:22 | don3 | Note Added: 0017544 | |
| 2015-10-29 17:22 | don3 | Status | new => resolved |
| 2015-10-29 17:22 | don3 | Resolution | open => fixed |
| 2015-10-29 17:22 | don3 | Assigned To | => don3 |
| 2015-10-29 18:31 | don3 | Note Added: 0017545 | |
| 2020-04-19 20:17 | system | Note Added: 0023555 | |
| 2020-04-19 20:17 | system | Status | resolved => closed |
