View Issue Details

IDCategoryLast Update
0000560features2014-12-18 07:28
ReporterjhallAssigned Todrobilla 
Status resolvedResolutionfixed 
Product Version 
Fixed in Version 
Summary0000560: mute automation does not work as expected
DescriptionSetting automation state to Write on an audiotrack then performing mute operations has no lasting effect when playing back automation events
Additional Informationhow 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.
TagsNo tags attached.

Users sponsoring this issue
Sponsors List Total Sponsorship = US$ 10

2009-04-07 23:36: zlp (US$ 10)
Users sponsoring this issue (Total Sponsorship = US$ 10)



2004-06-23 13:24

administrator   ~0001091

there is no mute automation.

Mark Knecht

2004-11-11 14:50

reporter   ~0001588

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.



2009-04-07 23:30

reporter   ~0005864

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:
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: )


2009-04-08 00:34

administrator   ~0005866

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.


2009-04-11 17:12

reporter   ~0005886

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.)


2014-12-18 07:28

developer   ~0016060

Mute automation finished in 3.5-4004-ge584ae0

Issue History

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