Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000560 [ardour] features minor always 2004-06-23 05:25 2014-12-17 23:28
Reporter jhall View Status public  
Assigned To drobilla
Priority low Resolution fixed  
Status resolved   Product Version
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.
Attached Files

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

2009-04-07 16:36: zlp (US$ 10)

- Relationships

-  Notes
(0001091)
paul (administrator)
2004-06-23 06:24

there is no mute automation.
(0001588)
Mark Knecht (reporter)
2004-11-11 06:50

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
(0005864)
zlp (reporter)
2009-04-07 16:30

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 [^] )
(0005866)
paul (administrator)
2009-04-07 17:34

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.
(0005886)
zlp (reporter)
2009-04-11 10:12

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.)
(0016060)
drobilla (developer)
2014-12-17 23:28

Mute automation finished in 3.5-4004-ge584ae0

- Issue History
Date Modified Username Field Change
2004-06-23 05:25 jhall New Issue
2004-06-23 06:24 paul Note Added: 0001091
2004-06-23 06:24 paul Priority urgent => low
2004-06-23 06:24 paul Status new => acknowledged
2004-11-11 06:50 Mark Knecht Note Added: 0001588
2009-04-07 16:30 zlp Note Added: 0005864
2009-04-07 16:36 zlp Sponsorship Added zlp: US$ 10
2009-04-07 16:36 zlp Sponsorship Total 0 => 10
2009-04-07 16:36 zlp Issue Monitored: zlp
2009-04-07 17:34 paul Note Added: 0005866
2009-04-11 10:12 zlp Note Added: 0005886
2009-10-20 14:09 cth103 cost => 0.00
2009-10-20 14:09 cth103 Category bugs => features
2010-07-22 07:48 oofus Target Version => 3.X
2014-12-17 23:28 drobilla Note Added: 0016060
2014-12-17 23:28 drobilla Assigned To => drobilla
2014-12-17 23:28 drobilla Status acknowledged => resolved
2014-12-17 23:28 drobilla Resolution open => fixed


Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker