View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004971 | ardour | bugs | public | 2012-07-01 07:53 | 2012-07-25 12:23 |
| Reporter | BenSpector | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Target Version | 3.0 | ||||
| Summary | 0004971: Writing automation in two separate places on the same track will create a diagonal line. | ||||
| Description | See attached movie. | ||||
| Tags | No tags attached. | ||||
|
2012-07-01 07:53
|
|
|
|
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. |
|
|
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
|
|
|
|
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. |
|
|
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. |
|
|
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. |
|
|
amazingly, we already have code that ought to do this, so its just a malfunction rather than missing design ... |
|
|
Or what we call "Bug" :-) |
|
|
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. |
|
|
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. |
|
|
"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. |
| 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 |
