View Issue Details

IDProjectCategoryView StatusLast Update
0004971ardourbugspublic2012-07-25 12:23
ReporterBenSpector Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
Target Version3.0 
Summary0004971: Writing automation in two separate places on the same track will create a diagonal line.
DescriptionSee attached movie.
TagsNo tags attached.

Activities

2012-07-01 07:53

 

paul

2012-07-06 18:15

administrator   ~0013796

i'm not sure how else this is supposed to work.

there is a single automation data set for the parameter. it begins where it begins, and ends where it ends. i can see now way for ardour to know that the user doesn't want to see what will happen (interpolation) between the two separate automation write passes.

i suspect that you may even be suggesting that ardour should *not* interpolate between them - i don't agree with this.

BenSpector

2012-07-08 09:20

reporter   ~0013808

What I suggest is what other DAWs do.
When an automation track is created, it comes with automation data already written to it, a strait line in the value of the controller.
That is very useful and gives you the option to edit instead of record. (lets say if you need a little bit more vocals in the chorus, you just select it and trim-up)
Then, of course, you will not need to interpolate.
See new movie.

2012-07-08 09:23

 

paul

2012-07-08 14:20

administrator   ~0013812

ardour also "comes with automation data already written to it, a strait line in the value of the controller."

and now i understand your point, which is that you want the existing straight line to continue to exist between the two sections of written data. i think that what is happening here is that ardour considers the initial straight line to be less meaningfull than anything the user explicitly does, and basically ignores the implicit existence of the straight line between two pieces of user-created data.

this does seem odd. i'll have a think about it - i don't think that changing the behaviour should be too hard.

oofus

2012-07-09 00:40

developer   ~0013814

I agree 100% with Ben here, this is a good example of the type of fundamental problems I have always thought Ardour has with automation.

paul

2012-07-09 01:38

administrator   ~0013815

this is actually exceptionally easy to solve. the fix simply involves adding a point with the default value at the beginning and end of each written automation section. will fix it up tomorrow.

paul

2012-07-09 02:22

administrator   ~0013816

amazingly, we already have code that ought to do this, so its just a malfunction rather than missing design ...

BenSpector

2012-07-09 08:42

reporter   ~0013817

Or what we call "Bug" :-)

paul

2012-07-09 19:34

administrator   ~0013823

this should be improved by commit 12997.

the PT approach shown in the movie has some drawbacks. i'm still evaluating whether to retain is "after a write/touch pass, the value returns to the default" or to return to ardour (and several consoles') behaviour where the most latest write/touch pass sets the value forward in time.

for ardour to do things the PT way, it is also important the dragging automation in range select mode works correctly, which it currently does not.

BenSpector

2012-07-10 11:07

reporter   ~0013831

Well, the new (?) trim range automation works great! Much better than PT!
But there are still lots of strange behaviors while using "Touch" mode.
The way I see it, after writing a strait line in 0.0 db there are (almost) no problems at all.
See attached movie.

the_CLA

2012-07-25 12:23

reporter   ~0013925

"i'm still evaluating whether to retain is "after a write/touch pass, the value returns to the default" or to return to ardour (and several consoles') behaviour where the most latest write/touch pass sets the value forward in time."

For Touch mode I would expect it to return to the value prior to the new automation pass in that position (as seen in the ProTools video above). I downloaded the ProTools 10.0 Reference Guide and they call it "AutoMatch" there.

For Write I wasn't sure, and obviously it is configurable in ProTools if AutoMatch is used for that mode. In the "Screen Recording 44.mov" it seems to be activated. It would be interesting to see how it would behave in the same position (with some other automation later on the timeline) when AutoMatch is switched off.

Also IMHO there are two notable things in BenSpector's video wich indicate how ProTools "thinks" about automation:

- The initial fader value on virgin territory is displayed as a single node at the start and the following line is infinite.

- During an automation pass the original values are still displayed and new automations are merely drawn as a kind of "correction" line. So it's allways clear to where the value is to return after a write pass that uses AutoMatch. Also note that there is a configurable "AutoMatch Time" to determine how fast it will return.

Issue History

Date Modified Username Field Change
2012-07-01 07:53 BenSpector New Issue
2012-07-01 07:53 BenSpector File Added: Screen Recording 8.mov
2012-07-02 21:45 cth103 cost => 0.00
2012-07-02 21:45 cth103 Target Version => 3.0
2012-07-06 18:15 paul Note Added: 0013796
2012-07-08 09:20 BenSpector Note Added: 0013808
2012-07-08 09:23 BenSpector File Added: Screen Recording 44.mov
2012-07-08 14:20 paul Note Added: 0013812
2012-07-09 00:40 oofus Note Added: 0013814
2012-07-09 01:38 paul Note Added: 0013815
2012-07-09 02:22 paul Note Added: 0013816
2012-07-09 08:42 BenSpector Note Added: 0013817
2012-07-09 19:34 paul Note Added: 0013823
2012-07-10 11:07 BenSpector Note Added: 0013831
2012-07-25 12:23 the_CLA Note Added: 0013925