Why automation recording is "stepped"?

Discussion of music production, audio, equipment and any related topics, either with or without Ableton Live
akm
Posts: 134
Joined: Sun Jan 30, 2005 9:47 pm

Re: Why automation recording is "stepped"?

Post by akm » Mon Sep 26, 2016 9:09 pm

"So we have now switched positions?"

Don't know, maybe D

Look, how would you suggest to implement the following scenario: after some fader movement you stop it at, say, 100. Then after a minute of doing nothing you move it a bit to 99. Ok, the difference is little but would you prefer to see a 100 to 99 slope, step, or curve? Next, what if after a minute of doing nothing it suddenly become, say, 30 (theoretically and technically it is possible). Now what to choose?

fishmonkey
Posts: 4103
Joined: Wed Oct 24, 2007 4:50 am

Re: Why automation recording is "stepped"?

Post by fishmonkey » Mon Sep 26, 2016 9:15 pm

Stromkraft wrote:
akm wrote:Ok, I see. It leaves too much space for the software to guess or more preferences-settings, which Ableton try to avoid as much as possible. Now I think that it is really the best way to use this sort of automation as it is now (plus thinning settings) and to later correct it manually (especially using the Shift+Drag option).
No, I disagree. There is no guessing involved. The recorded data is as dense as it is and a curved representation would simply follow the data point curve as closely as possible in a one-off conversion into curved automation. Then you could edit if you want to.
it is not currently feasible for Live to automatically replace dense automation points with curves. it is simply too computationally intense.

you are talking about replacing lots of points with mathematical curve functions. to do that, firstly you need to decide what kind of curve to fit (there are lots of choices, with various tradeoffs). curve fitting is non-trivial. and then the automation needs to be stored as math functions instead of simple cartesian data points. then on playback the functions need to be solved to work out the actual automation values...
badbrainz wrote: I'm a drummer, so I'm already at an intellectual disadvantage here

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: Why automation recording is "stepped"?

Post by Stromkraft » Mon Sep 26, 2016 10:45 pm

fishmonkey wrote:
you are talking about replacing lots of points with mathematical curve functions. to do that, firstly you need to decide what kind of curve to fit (there are lots of choices, with various tradeoffs). curve fitting is non-trivial. and then the automation needs to be stored as math functions instead of simple cartesian data points. then on playback the functions need to be solved to work out the actual automation values...
Most of that is already happening when hand editing with curves. The conversion would be a one-off and could be made inter-active. It would play back just as with hand edited curved automation, so I do not see how you can bring an argument against that as curved automation is already there.

The main argument against this as I see it is that the return is small in concrete musical benefits. The benefits are more cosmetic than practical. That may be enough though as it could make post-recorded automation control easier for the user.
Make some music!

fishmonkey
Posts: 4103
Joined: Wed Oct 24, 2007 4:50 am

Re: Why automation recording is "stepped"?

Post by fishmonkey » Mon Sep 26, 2016 11:05 pm

drawing curved automation with preset curve types is very different to curve fitting to existing data points...
badbrainz wrote: I'm a drummer, so I'm already at an intellectual disadvantage here

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: Why automation recording is "stepped"?

Post by Stromkraft » Tue Sep 27, 2016 8:02 am

fishmonkey wrote:drawing curved automation with preset curve types is very different to curve fitting to existing data points...
And is very doable these days. Not simple necessarily, but doable and not more complicated mathematically than what Live is already doing more or less successfully. I don't find this argument very convincing at all. What is LFO smoothing of an erratic movement if not what I'm talking about? That simplifies existing data into curves.

Even so as the return in pure musical terms is likely small this functionality may not be worth pursuing. After all curves still yields the same automation data as the range of possible data points are limited.
Make some music!

fishmonkey
Posts: 4103
Joined: Wed Oct 24, 2007 4:50 am

Re: Why automation recording is "stepped"?

Post by fishmonkey » Tue Sep 27, 2016 8:39 am

Stromkraft wrote:
fishmonkey wrote:drawing curved automation with preset curve types is very different to curve fitting to existing data points...
And is very doable these days. Not simple necessarily, but doable and not more complicated mathematically than what Live is already doing more or less successfully. I don't find this argument very convincing at all. What is LFO smoothing of an erratic movement if not what I'm talking about? That simplifies existing data into curves.

Even so as the return in pure musical terms is likely small this functionality may not be worth pursuing. After all curves still yields the same automation data as the range of possible data points are limited.
i can only suggest you do some research into curve fitting, and have a think about how you would implement that in a general sense by trying a few real-world examples. it is nowhere near as straightforward as you imagine.

an already very big problem is when and where should the curve fitting start? algorithmically, there is no right answer.
badbrainz wrote: I'm a drummer, so I'm already at an intellectual disadvantage here

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: Why automation recording is "stepped"?

Post by Stromkraft » Tue Sep 27, 2016 8:36 pm

fishmonkey wrote:
i can only suggest you do some research into curve fitting, and have a think about how you would implement that in a general sense by trying a few real-world examples. it is nowhere near as straightforward as you imagine.

an already very big problem is when and where should the curve fitting start? algorithmically, there is no right answer.
Who said this needs to be straightforward? All development comes with a cost. That's why I mentioned the possibly meagre returns on the investment to achieve this functionality.

I might try some real world examples when I get into MFL programming, but it's not my call to evaluate how hard a feature is. I trust Ableton to be able to evaluate suggestions, both for potential value and implementation.
Make some music!

fishmonkey
Posts: 4103
Joined: Wed Oct 24, 2007 4:50 am

Re: Why automation recording is "stepped"?

Post by fishmonkey » Wed Sep 28, 2016 12:23 am

Stromkraft wrote:
fishmonkey wrote:
i can only suggest you do some research into curve fitting, and have a think about how you would implement that in a general sense by trying a few real-world examples. it is nowhere near as straightforward as you imagine.

an already very big problem is when and where should the curve fitting start? algorithmically, there is no right answer.
Who said this needs to be straightforward? All development comes with a cost. That's why I mentioned the possibly meagre returns on the investment to achieve this functionality.

I might try some real world examples when I get into MFL programming, but it's not my call to evaluate how hard a feature is. I trust Ableton to be able to evaluate suggestions, both for potential value and implementation.
that is a weird combative reply.

anyway, you don't need to do any programming to get a handle on it.

the—most likely insurmountable—problem for general, automatic curve fitting to all automation data is that by its very nature automation has lots of discontinuities. by that i mean that one section of automation is likely to have no mathematical relationship to the surrounding automation. curve fitting in that context is fraught with difficulties.

one simple example: say we have some basic volume automation where the level starts high, suddenly drops lower, and then sits at this constant lower level for an extended period, before then jumping back up to the higher level again (in context this might be chorus-verse-chorus). how do you—without human intervention—fit a satisfactory curve to that data, one that does not fundamentally change the intent of the person who recorded the automation?

if you have ever done any curve fitting, you will see that this is a very difficult problem.
badbrainz wrote: I'm a drummer, so I'm already at an intellectual disadvantage here

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: Why automation recording is "stepped"?

Post by Stromkraft » Wed Sep 28, 2016 9:59 pm

fishmonkey wrote: that is a weird combative reply.
Say what?
fishmonkey wrote: anyway, you don't need to do any programming to get a handle on it.
OK.
fishmonkey wrote: one simple example: say we have some basic volume automation where the level starts high, suddenly drops lower, and then sits at this constant lower level for an extended period, before then jumping back up to the higher level again (in context this might be chorus-verse-chorus). how do you—without human intervention—fit a satisfactory curve to that data, one that does not fundamentally change the intent of the person who recorded the automation?

if you have ever done any curve fitting, you will see that this is a very difficult problem.
Maybe so, but this type of thing is already being handled by the thinning settings which are basically already doing the same thing just not adding curved automation data.

I don't see why this couldn't be an option where the user selects the automation data to be processed and apply some direction in difficult areas.
I of course think you're right there are specific difficult problems that may arise. My view is that this type of problems are already handled in different places in Live, sometimes with opinionated processes, like when you smooth out LFO. It's not a perfect process, it's just a different result. That's acceptable I think. So this would not appear to be impossible to solve.

Maybe this kind of functionality is best handled in a MFL device first.
Make some music!

fishmonkey
Posts: 4103
Joined: Wed Oct 24, 2007 4:50 am

Re: Why automation recording is "stepped"?

Post by fishmonkey » Wed Sep 28, 2016 11:01 pm

Stromkraft wrote: Maybe so, but this type of thing is already being handled by the thinning settings which are basically already doing the same thing just not adding curved automation data.

I don't see why this couldn't be an option where the user selects the automation data to be processed and apply some direction in difficult areas.
I of course think you're right there are specific difficult problems that may arise. My view is that this type of problems are already handled in different places in Live, sometimes with opinionated processes, like when you smooth out LFO. It's not a perfect process, it's just a different result. That's acceptable I think. So this would not appear to be impossible to solve.

Maybe this kind of functionality is best handled in a MFL device first.
thinning is not basically the same as curve fitting.

yes, if human intervention is involved then it certainly is possible. but i thought we were talking about automatic background processing? if the user needs to select areas and guide the process then i don't see how that improves the current system?

also, LFO smoothing is a very different situation. unlike general automation, an LFO by definition is based upon a mathematical function that has an inherent predictable form.
badbrainz wrote: I'm a drummer, so I'm already at an intellectual disadvantage here

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: Why automation recording is "stepped"?

Post by Stromkraft » Thu Sep 29, 2016 8:22 am

fishmonkey wrote: thinning is not basically the same as curve fitting.
Thinning is a process that takes data point and limits them to fewer. What I was trying to get across is that a curved function would work the same and using data points as guides for what curve to use. The goal shouldn't be to make a perfect replica of raw data, that would be of little value, but a thinned version where curves would approximate, not replicate, raw data.
fishmonkey wrote: yes, if human intervention is involved then it certainly is possible. but i thought we were talking about automatic background processing? if the user needs to select areas and guide the process then i don't see how that improves the current system?
If it works perfectly it could be automatic. You're suggetsting some problems. This functionality would give the user a method to get curved automation data closer to the original set, yet more editable, faster than by hand.
fishmonkey wrote: also, LFO smoothing is a very different situation. unlike general automation, an LFO by definition is based upon a mathematical function that has an inherent predictable form.
No, this is an assumption you make. I was obviously referring to swift chaotic LFO data. The mathematics exists. It's more a question of what data to discard that poses the problem you seem to want to put forward here. Approximation, discarding deviant data points and opinionated processing could make this work.

We're not going to build this, so I note that we disagree. I appreciate your concerns for such an idea. Insightful and useful. Thank you.
Make some music!

Post Reply