CPU usage of complex automation

[Mushy Mushy]

I've often wondered if complex automation, say constant wiggly lines on 32nd notes, uses more CPU than simply a straight line upward or downward over multiple bars.

Logically you'd say yes because it's more complex. However to a computer it's just a point of data at a particular time, and in this regard there's no difference

Thoughts?

[Psuper]

Automation load = Midi load which is virtually nothing -- all depends on how efficient the instrument being controlled is.

[Mushy Mushy]

Automation load = Midi load which is virtually nothing -- all depends on how efficient the instrument being controlled is.

Ah, interesting. Thanks for that.
It makes little difference to delete all the unused automation curves then like I usually do.

[vurt]

well it makes it tidier and you can see what youre doing.

[Mushy Mushy]

well it makes it tidier and you can see what youre doing.

How are those cables going?

[vurt]

well it makes it tidier and you can see what youre doing.

How are those cables going?

well it gets easier when i remove the ones that arent plugged in

[Mushy Mushy]

well it makes it tidier and you can see what youre doing.

How are those cables going?

well it gets easier when i remove the ones that arent plugged in

ha, touche

[antic604]

I'd say it depends - if you're for example automating delay's feedback or time, reverb's size, some complex temporal effects like stutters / glitches then It can have some impact. I imagine even sweeping a filter takes few CPU cycles to recalculate the FFT, so the more frequently you do it, the bigger the CPU 'hit'.

So in theory it makes a difference, but more often than not it's negligible.

[Mushy Mushy]

I'd say it depends - if you're for example automating delay's feedback or time, reverb's size, some complex temporal effects like stutters / glitches then It can have some impact. I imagine even sweeping a filter takes few CPU cycles to recalculate the FFT, so the more frequently you do it, the bigger the CPU 'hit'.

So in theory it makes a difference, but more often than not it's negligible.

My point is that as far as a CPU is concerned theres no difference between these two automation lanes:

1.1, 1.2, 1.3, 1.4, 1.5, etc

vs

1,127,5,122,10,1,90

The bottom one would appear complex to a human but to a computer they're exactly the same (different points at different times).

[antic604]

I'd say it depends - if you're for example automating delay's feedback or time, reverb's size, some complex temporal effects like stutters / glitches then It can have some impact. I imagine even sweeping a filter takes few CPU cycles to recalculate the FFT, so the more frequently you do it, the bigger the CPU 'hit'.

So in theory it makes a difference, but more often than not it's negligible.

My point is that as far as a CPU is concerned theres no difference between these two automation lanes:

1.1, 1.2, 1.3, 1.4, 1.5, etc

vs

1,127,5,122,10,1,90

The bottom one would appear complex to a human but to a computer they're exactly the same (different points at different times).

Oh, I thought of complex as more dense, even up to audio rate.

But even in your example, it can be that automated parameter isn't continuous but discrete, so small changes are taken from a lookup table or inter/extrapolated, but bigger ones need to be recalculated. Or the plugin might use oversampling, so it will actually go through more discrete steps if the range is higher to avoid aliasing, which means it needs to perform more calculations...

Obviously I'm just speculating and - as I said - in most cases it probably is irrelevant.

[airon]

It depends entirely on the plugin you're automating and the speed of the interpolation algorithms for the automation data.

Acon Digitals Reverb was not good to automate in v1, but v2 was fine. Some plugins need more CPU for specific parameters changing, and they do it more gracefully with a sudden jump than one that takes several seconds or longer. Trial and error. Good thing we have so many choices these days.