View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000560 | ardour | features | public | 2004-06-23 12:25 | 2020-04-19 20:12 |
| Reporter | jhall | Assigned To | drobilla | ||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 3.X | ||||
| Summary | 0000560: mute automation does not work as expected | ||||
| Description | Setting automation state to Write on an audiotrack then performing mute operations has no lasting effect when playing back automation events | ||||
| Additional Information | how to reproduce: 1: at->set_gain_automation(Write); 2: roll transport in play mode 3: perform mute operations on the route 4: perform gain adjustments on the route 5: disable Write automation and enable Play automation 6: go back and play the session again you will notice your mutes aren't remembered. | ||||
| Tags | No tags attached. | ||||
| Users sponsoring this issue | ||
| Sponsors List |
Total Sponsorship = US$ 10 2009-04-07 23:36: zlp (US$ 10) |
|
|---|---|---|
|
|
there is no mute automation. |
|
|
Please consider adding track mute automation to the editor just like volume and pan. You should be able to edit mute using line segments similar to editing volume, except the segments go between 0 and 1 only. There is not reason from my POV to do this for solo. Thanks |
|
|
Also see this forum thread from 2009 about plugin bypass automation and my 2 cents regarding Ardour's handling of boolean parameters in the automation window: http://ardour.org/node/933 I suggest quantizing all automation drawing to match each individual parameter instead of always using floats (the current behavior as of 2.7.1). If such a system were in place, mute automation would fit nicely into the interface, automatically snapping to "on" or "off" (as would other parameters like plugin bypass, requested here: http://tracker.ardour.org/view.php?id=293 ) |
|
|
unfortunately this kind of idea just isn't correct. current automation data consists of a discrete set of (time,value) pairs. when drawing the data, we just thin the data and draw a regular x-y graph. boolean automation cannot be drawn in this same simplistic way. every place where is an "event" has to be represented by two points in the GUI, to show the transition from on to off. drawing the line this way is not too hard, but now editing has to be dealt with. these points used to plot the line are no longer independent elements, but always have to move as pairs. its not brain surgery, but its not trivial either. |
|
|
Thanks for the explanation. Paul. I now see the challenge. Alas, my programming chops are limited to MAX and PD, with a light sprinkling of processing and javascript, so I can be of little help here. My first thought would be, why not use 4 array elements for the time/value storage of each automation point, knowing that they would be redundant for float parameters, but allowing them to be different for non-floats (like mute). But that would seem to break session compatibility. I wonder if all automation operations could loop through a check of parameter units first, so the pressing of a mute button would trigger a check of what units are possible for "mute", before logging the x,y value. If mute is found to have non-float units, then loop through 2 passes at this time-location to mark the end of one state and beginning of the next, (rounding off the recorded value to the unit system of the param). Then we drop 2 "events" on the timeline at the same time-location (an "out" first and then an "in"). These events might still fit into the existing paradigm because they look like separate time/value pairs that happen to share the same value. (maybe this is deal-breaker if the thinning algo is stripping such nonsense anyway) If we edit the automation later, the routine for handling the drawing would loop through the same check. If we discover that we're editing a non-float parameter, we look for the other entry at this time-location and also follow it to the next or previous entry with the same value. Our changes effect the state of the current point (snapping our cursor to the param units) as well as the next/previous point that we found. This could lead to in and out points having exactly the same value, leaving behind a useless point where we make a transition from "unmute" to "unmute", but that's actually useful for me when it happens in Pro Tools, because it saves my position so I can re-mute the area later without drawing more points. It sounds un-trivial indeed! But if it were done, it would seem to kill a few birds with one stone (mute automation, plugin bypass, plugin params with arbitrary int units - like Jamin scenes). I can do screencasts of how this behaves in Pro Tools if it would help anybody. (I realize that the challenge for the devs is not in comprehending the problem itself, but finding the resources to tackle it. Alas, explicating it is about all I can do.) |
|
|
Mute automation finished in 3.5-4004-ge584ae0 |
|
|
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 |
|---|---|---|---|
| 2004-06-23 12:25 | jhall | New Issue | |
| 2004-06-23 13:24 | paul | Note Added: 0001091 | |
| 2004-06-23 13:24 | paul | Priority | urgent => low |
| 2004-06-23 13:24 | paul | Status | new => acknowledged |
| 2004-11-11 14:50 | Mark Knecht | Note Added: 0001588 | |
| 2009-04-07 23:30 | zlp | Note Added: 0005864 | |
| 2009-04-07 23:36 | zlp | Sponsorship Added | zlp: US$ 10 |
| 2009-04-07 23:36 | zlp | Sponsorship Total | 0 => 10 |
| 2009-04-08 00:34 | paul | Note Added: 0005866 | |
| 2009-04-11 17:12 | zlp | Note Added: 0005886 | |
| 2009-10-20 21:09 | cth103 | cost | => 0.00 |
| 2009-10-20 21:09 | cth103 | Category | bugs => features |
| 2010-07-22 14:48 | oofus | Target Version | => 3.X |
| 2014-12-18 07:28 | drobilla | Note Added: 0016060 | |
| 2014-12-18 07:28 | drobilla | Assigned To | => drobilla |
| 2014-12-18 07:28 | drobilla | Status | acknowledged => resolved |
| 2014-12-18 07:28 | drobilla | Resolution | open => fixed |
| 2020-04-19 20:12 | system | Note Added: 0021424 | |
| 2020-04-19 20:12 | system | Status | resolved => closed |
