View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000879 | ardour | bugs | public | 2005-02-04 18:45 | 2020-04-19 20:12 |
Reporter | nmains | Assigned To | paul | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Fixed in Version | SVN/2.0-ongoing | ||||
Summary | 0000879: [PATCH] automation write mode moves control | ||||
Description | in normal use, a suitable value for a control (fader, plugin slider etc.) is found, then the control is left alone. if automation is later required, selecting 'write' will move the control to it's default value, making it necessary to find the desired initial value again. could 'write' leave the control where it is currently? | ||||
Tags | No tags attached. | ||||
|
I don't understand how this is related to 922? |
|
oh yes, please. this issue is still present in ardour 2.8.1, and it is extremely annoying while (hopefully) easy to fix. this is a huge usability issue that should be addressed. i'd even consider it "data loss", because it fscks up a perfectly good mix just because you want to add some automation afterwards. therefore, i'd like to propose to up this bug to *major* status. it can also be quite nasty when you use it while a signal is playing - thinking you are safely operating at -40dB and having the fader jump to unity gain can damage both ears and equipment.... |
2009-07-01 00:29
|
879.patch (649 bytes)
diff --git a/libs/ardour/io.cc b/libs/ardour/io.cc index 7d9734d..ad37662 100644 --- a/libs/ardour/io.cc +++ b/libs/ardour/io.cc @@ -2584,8 +2584,11 @@ IO::set_gain_automation_state (AutoState state) changed = true; last_automation_snapshot = 0; _gain_automation_curve.set_automation_state (state); - - if (state != Off) { + + /* don't reset gain if we're moving to Off or Write mode; + if we're moving to Write, the user may have manually set up gains + that they don't want to lose */ + if (state != Off && state != Write) { set_gain (_gain_automation_curve.eval (_session.transport_frame()), this); } } |
|
Attached a patch which should fix this. Can't think of any unpleasant side-effects, though they may well exist! Comments welcome. |
|
Patch applied to 2.0-ongoing SVN, so this should be fixed. |
|
nettings has some more input. |
|
using r5499, i find the bug is only partially fixed: fader automation works as expected. when moving from "manual" to "write", the current, manually set fader position is retained always. not so for the panners (tested both 2ch->stereo and 1ch->stereo): when switching from "manual" to "write", and no automation data exists, the panner jumps to a default (hard left/right for the 2ch one, center for the 1ch one). if there has been previous automation data, it jumps to the last automation value. imho "write" should always imply that a new automation node is created with the current setting. the same (wrong) behaviour can be seen on plugin automation: in the absence of previous data, the value jumps to some default when going from "manual" to "write". if there exists previous automation data, it jumps to the value of the last automation node. |
2009-10-28 22:19
|
879.2.patch (1,302 bytes)
diff --git a/libs/ardour/insert.cc b/libs/ardour/insert.cc index 03b56e5..d931f3a 100644 --- a/libs/ardour/insert.cc +++ b/libs/ardour/insert.cc @@ -166,7 +166,10 @@ PluginInsert::auto_state_changed (uint32_t which) { AutomationList& alist (automation_list (which)); - if (alist.automation_state() != Off) { + /* don't reset automation if we're moving to Off or Write mode; + if we're moving to Write, the user may have manually set up automation + that they don't want to lose */ + if (alist.automation_state() != Off && alist.automation_state() != Write) { _plugins[0]->set_parameter (which, alist.eval (_session.transport_frame())); } } diff --git a/libs/ardour/panner.cc b/libs/ardour/panner.cc index d626ec4..473354d 100644 --- a/libs/ardour/panner.cc +++ b/libs/ardour/panner.cc @@ -224,8 +224,11 @@ BaseStereoPanner::set_automation_state (AutoState state) if (state != _automation.automation_state()) { _automation.set_automation_state (state); - - if (state != Off) { + + /* don't reset pan if we're moving to Off or Write mode; + if we're moving to Write, the user may have manually set up pans + that they don't want to lose */ + if (state != Off && state != Write) { set_position (_automation.eval (parent.session().transport_frame())); } } |
|
879.2.patch (attached) should fix the other two cases. |
|
committed to 2.X, rev 5988 |
|
works for me now. thanks! |
|
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 |
---|---|---|---|
2005-02-04 18:45 | nmains | New Issue | |
2008-11-21 20:02 | seablade | Relationship added | has duplicate 0001649 |
2008-11-21 20:04 | seablade | Relationship added | has duplicate 0000922 |
2008-11-22 13:06 | peppot | Note Added: 0005288 | |
2008-11-24 08:33 | seablade | Status | new => confirmed |
2009-06-29 10:56 | nettings | Note Added: 0006199 | |
2009-07-01 00:29 | cth103 | File Added: 879.patch | |
2009-07-01 00:30 | cth103 | Note Added: 0006202 | |
2009-07-01 00:30 | cth103 | Status | confirmed => feedback |
2009-07-01 22:49 | cth103 | cost | => 0.00 |
2009-07-01 22:49 | cth103 | Note Added: 0006204 | |
2009-07-01 22:49 | cth103 | Status | feedback => resolved |
2009-07-01 22:49 | cth103 | Fixed in Version | => SVN/2.0-ongoing |
2009-07-01 22:49 | cth103 | Resolution | open => fixed |
2009-07-01 22:49 | cth103 | Assigned To | => cth103 |
2009-08-13 16:37 | paul | Note Added: 0006512 | |
2009-08-13 16:37 | paul | Status | resolved => feedback |
2009-08-13 16:37 | paul | Resolution | fixed => reopened |
2009-08-13 16:46 | nettings | Note Added: 0006513 | |
2009-10-28 01:45 | cth103 | Assigned To | cth103 => |
2009-10-28 01:45 | cth103 | Status | feedback => new |
2009-10-28 22:19 | cth103 | File Added: 879.2.patch | |
2009-10-28 22:20 | cth103 | Note Added: 0006918 | |
2009-10-28 22:20 | cth103 | Assigned To | => paul |
2009-10-28 22:20 | cth103 | Status | new => assigned |
2009-10-28 22:20 | cth103 | Summary | automation write mode moves control => [PATCH] automation write mode moves control |
2009-10-30 17:43 | paul | Note Added: 0007000 | |
2009-10-30 17:43 | paul | Status | assigned => resolved |
2009-10-30 17:43 | paul | Resolution | reopened => fixed |
2009-11-03 11:57 | nettings | Note Added: 0007068 | |
2020-04-19 20:12 | system | Note Added: 0021446 | |
2020-04-19 20:12 | system | Status | resolved => closed |