default automated values to the first related automation node

[Itreza2]

this PR aim to close #8304

Adds a loop at the beginning of TrackContainer::automatedValuesFromTracks that iterates through the automation clips that begin after the parameter time in descending order and sets the value of their first node as the value of the associated models.

The complexity of the method is impacted in a non-negligible way but retains the same order of magnitude.

[sakertooth]

Will this break projects? If there was an automated linear riser at t = 10 that started from 0 and went to 100 on some parameter, with this PR, does that mean between t = 0 and t = 9, the knob will be at a fixed value of 0? In current master, the knob will be left alone between t = 0 and t = 9.

[Itreza2]

Will this break projects? If there was an automated linear riser at t = 10 that started from 0 and went to 100 on some parameter, with this PR, does that mean between t = 0 and t = 9, the knob will be at a fixed value of 0? In current master, the knob will be left alone between t = 0 and t = 9.

Yes, but from my perspective, this will "fix" such projects.
Currently, the knob between t=0 and t=9 could get different values depending on where the song was previously interrupted, and you would have to create an "init" automation clip at t=0 to circumvent this. Also, it doesn't feel right that automated values are fixed after the last clip for the duration of the song but not before the first clip.

To avoid confusion, I was thinking about the possibility of adding a visual queue on knobs that are automated (coloring them in purple instead of green of something like this...).

[sakertooth]

I am aware of the init automation clip problem, but this causes another problem AFAICT. To create a linear rider automation, I usually start my automation at the very bottom of the automation editor and then I go up to 100. If in that previous example t=0 and t=9 are fixed at values of 0 with these changes, this won't work and is not backwards compatible.

When it comes to backwards compatibility, there isn't too much concern about differing perspectives. The main thing is that if it is a change that fundamentally changes the project in such to emit a different output in sound, the project won't sound or operate the same across different versions.

In my case, to fix the init automation clip problem, I jump the timeline to the very end of my song before exporting (which sets them to 100), But now with these changes that won't work as I understand it now.

Though who knows, there might be a misunderstanding so I'll need to test this to be sure.

[messmerd]

If we're worried about some edge cases where some projects may break, could we add an upgrade routine for old projects? Or a config file option that reverts it back to the old behavior?

[sakertooth]

I'm still trying to understand how this would fix the init automation clip problem. I mean, in a way it would, since values before the first automation clip have a deterministic value, but the problem here is the way that deterministic value is retrieved. I don't think it should grab the first node of the nearest automation clip further along the timeline. If that value was user defined and defaulted to the default knobs value, that could be a possible solution. I'll have to do some more thinking/research about this though.

[Itreza2]

Though who knows, there might be a misunderstanding so I'll need to test this to be sure.

You understand it perfectly well I think. The behavior I'm proposing is the one that feel the most natural for me, but I can also understand your point of view. Unfortunately I have no idea to address your concerns.

If that value was user defined and defaulted to the default knobs value, that could be a possible solution.

I thought about this, but these two solutions have their own issues to :

• A user defined default would be the same as creating a clip at the beginning of the song, and it would also be pretty unintuitive if the functionality is hidden in some context menu.
• Using the knob default make sense, but it might be confusing as nothing in the song editor UI would indicate why the knob is stuck at this arbitrary value until the first automation clip. Furthermore, this solution have the same complexity as the one I'm proposing, so there is no benefit from this pov too.

[sakertooth]

I've been doing some research into how other DAWs handle this. FL Studio handles this by using a feature known as "Initialized controls". Each automatable knob has a context menu option called "Init song with this position", which will initialize the knob to have its starting value be the value when the option was pressed. These init values can be set manually or can be set to happen automatically (not seeing where the option to disable this is in the manual, though it was mentioned the automatic behavior could be disabled elsewhere in it).

I think this is a good solution and was my general idea I believe:

If that value was user defined and defaulted to the default knobs value, that could be a possible solution.

[Itreza2]

If other DAWs are doing it this way, then I guess there is no need to reinvent the wheel...
I will try it for myself and, if convinced, will update this pr accordingly.

[sqrvrt]

Will this break projects? If there was an automated linear riser at t = 10 that started from 0 and went to 100 on some parameter, with this PR, does that mean between t = 0 and t = 9, the knob will be at a fixed value of 0? In current master, the knob will be left alone between t = 0 and t = 9.

There's a very automatic possible fix to this, when an project is upgraded it could seek the first automation clip for every automated parameter and make its first inValue an outValue, while setting the inValue to the "current" volume on project load.

I think there are only two possible scenarios where it wouldn't work perfectly, first being if the playhead was not where it's supposed to be when project was saved (could source automation at the end of the track instead to fix; i don't really understand how the breakage in your case occurs), and second being that someone, somehow, bound two different things to the same automation track, without having an init value for either. This is kind of unfixable without splitting the automation, at which point i don't know how much of it would even pay off.

[sqrvrt]

in case someone wants to make a new automation clip that starts with a sudden jump, the automation pattern starts with the current value of the knob, so the only thing they'd need to do is to set the outvalue instead of moving the entire point down. Don't know about you, but to me it looks very intuitive, at least once you know about in/out values.