# Sample accurate parameter automation? **URL:** \ **Category:** Audio Plugins\ **Created:** [February 20, 2022, 2:33pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277 "2022-02-20T14:33:40Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Mrugalla](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mrugalla/32/13092_2.png) [@Mrugalla](https://forum.juce.com/u/Mrugalla)\ **Post date:** [February 21, 2022, 8:00am UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/21 "2022-02-21T08:00:50Z")
> [@eyalamir](#): > > sample accurate parameters will not magically make parameter smoothing unneeded, as parameters are also modified from the UI, or from stepped automation that isn’t smoothed, and the plugin needs to make sure those transitions sound good. you’re not thinking far enough here. yes, you might still need to smoothen the parameter changes coming from the GUI, but imagine how cool it would be if at least the motions that come from outside of the plugin could be unsmoothed? like you could have a sample-accurate temposync LFO modulating anything in a plugin, or an envelope follower where quick changes in the modulation signal are often desirable. > [@eyalamir](#): > > In terms of implementation, slicing the buffer for smaller sections is a very valid way to do sample accurate automation, but it also spikes the CPU due to the smaller buffer sizes, so I think it should be up to the plugin to decide if it wants to do it that way, VS read the parameter changes as stamped events (similar to MIDI messages). stamped events is the way to go then imo. i don’t think automation will be the main thing people use to modulate parameters in the future anymore. imagine modulators constantly doing something with plugin parameters. that would mean that the cpu can never take a break if it is solved by making the buffer small. and if that happens on almost every track in the project you’d need a super computer to finish any reasonably complex piece of music. edit: i just kept on reading the rest of the post and saw you actually considered most of this, so you are thinking far enough indeed. nice nice. so. roadmap pls \<3 ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 21, 2022, 6:23pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/22 "2022-02-21T18:23:19Z")
> [@xenakios](#): > > All hosts don’t do that. The only one I am even aware of is FL Studio. Really ? are you sure Reaper does not provide this ? Would be easy to be tested by moving the parameter by a CC and sending the same CC directly to the plugin. Could be checked for JSFX plugins, but of course there parameter modulation works different from VST3. But if not provided for JSFX it’s unlikely that VST3 is supported on that. BTW.: AFAIU, the first version of VST3 did not even allow for Midi CC, and they tried (unsuccessfully) to force DAW and plugin providers to use sample accurate parameter modulation instead. BTW2.: AFAIU, with VST3 API, Parameter modulation ALWAYS is sample accurate, Of course DAWs and Plugins (like JUCE) might fake the point of time to be the start (or center) of a block. -Michael ---
**Author:** ![xenakios](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/xenakios/32/4047_2.png) [@xenakios](https://forum.juce.com/u/xenakios)\ **Post date:** [February 21, 2022, 6:27pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/23 "2022-02-21T18:27:21Z")
Yes, I’ve checked sample accurate automation works in Reaper for _VST3_ (and Jesusonic), but at least back when I was still actively following Reaper’s development (back in 2020), they had not done anything for _VST2_ plugins to alleviate the automation update frequency issue. So, for example, if you have your audio hardware set to 1024 samples, the VST2 plugin automations would only be updated every 1024 samples etc. Anyway, VST2 plugins have become a moot point by now. New ones can’t be published by new developers and Steinberg is even removing VST2 support from Cubase. The issue with Juce is now : will we ever get the sample accurate automation support for VST3, AU, AAX? ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 21, 2022, 6:31pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/24 "2022-02-21T18:31:58Z")
> [@eyalamir](#): > > All it needs to do is pass those parameters at sample position #0 in case the exact position is unknown. IMHO, sample accurate parameters would need do work exactly like MIDI events, as (1) this is obviously according to their purpose being the same as Midi CC, (2) programmers that already know how to do Midi programming don’t need to relearn anything, (3) no additional CPU overhead, (4) independent of Plugin format. Maybe enhancing the Midi event type appropriately might be the way to go Of course “standard” non-sample accurate parameter modulation should be provided in parallel. ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 21, 2022, 6:37pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/25 "2022-02-21T18:37:06Z")
> [@eyalamir](#): > > hosts can’t really handle smoothing like the plugin can Yep. Optimal smoothing decently depends on the audio algorithm the plugin does. Hence even Juce is not supposed to (always) provide it. -Michael ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 21, 2022, 6:46pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/26 "2022-02-21T18:46:46Z")
> [@xenakios](#): > > Yes, I’ve checked sample accurate automation works in Reaper for _VST3_ (and Jesusonic) OK, so I don’t need to do this. 🙂 But AFAIU, “automation” (curves) is on the realm of the ControlPath (GUI) Thread, and not on the track’s therad. hence it always will be sloppy. That is why I’d be interested to know this regarding parameter modulation from CC in track-Midi. > [@xenakios](#): > > but at least back when I was still actively following Reaper’s development (back in 2020), they had not done anything for _VST2_ plugins to alleviate the automation update frequency issue. So, for example, if you have your audio hardware set to 1024 samples, the VST2 plugin automations would only be updated every 1024 samples etc Is this even decently possible with VST2 ? AFAIU, there are DAWs that under the hood split sample blocks to provide more accurate parameter automation for VST2. IMHO not really a good idea, as there will be plugins that do not like this at all. > [@xenakios](#): > > Steinberg is even removing VST2 support from Cubase … will we ever get the sample accurate automation support for VST3? Obviously 🙂 -Michael ---
**Author:** ![xenakios](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/xenakios/32/4047_2.png) [@xenakios](https://forum.juce.com/u/xenakios)\ **Post date:** [February 21, 2022, 6:56pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/27 "2022-02-21T18:56:55Z")
> [@mschnell](#): > > OK, so I don’t need to do this. 🙂 But AFAIU, “automation” (curves) is on the realm of the ControlPath (GUI) Thread, and not on the track’s therad. hence it always will be sloppy. > That is why I’d be interested to know this regarding parameter modulation from CC in track-Midi. No, plugin parameter automation wouldn’t work from the GUI thread, that would be an insane design IMHO. (At least as far as I’ve observed, the automation changes from host envelopes happen in the audio thread. But who knows, maybe there’s some host or plugin format that does it differently.) MIDI CC messages are not the thing being discussed here. Those have already had sample accurate support even for VST2. But they are of very little use at least for effects plugins, because very few allow assigning MIDI CCs to their parameters. (Note that isn’t the same thing as the _host_ allowing the MIDI CC control of the parameters. The data flow is different with that. In that case the host captures incoming MIDI CC messages and turns those into regular plugin automation changes which are subject to the same limitations as the track automation envelopes.) ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [February 21, 2022, 6:59pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/28 "2022-02-21T18:59:31Z")
> [@mschnell](#): > > But AFAIU, “automation” (curves) is on the realm of the ControlPath (GUI) Thread, and not on the track’s therad. That is not quite correct. You can interfere with automation from the UI threead, which will necessarily lag behind (will be sloppy). But when you play back the automation it comes from the audio thread or a thread synchronised with the audio thread. And Midi CCs lack another property: an audio parameter knows how it should interpolate between two control values, which is not the case for midi CCs afaik. Plus the point @kamedin brought up, that in the default VST3 scenario the processor and the editor are separated, potentially even reside on physical different machines. ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 21, 2022, 7:02pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/29 "2022-02-21T19:02:07Z")
> [@xenakios](#): > > MIDI CC messages are not the thing being discussed here I was talking about Reaper converting Midi CCs to parameter modulation. I do use this all the time for parameters of plugins that are not provided as CC receives by those. Here it’s nasty that we loose sample accuracy with VST2. > [@xenakios](#): > > . But they are of very little use at least for effects plugins, because very few allow assigning MIDI CCs to their parameters. ?? with the VSTi plugins I use, most relevant parameters are provided as well in the UI as with DAW parameters as with Midi CCs. (But of course not ALL parameters). -Michael ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 21, 2022, 7:06pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/30 "2022-02-21T19:06:09Z")
> [@daniel](#): > > But when you play back the automation it comes from the audio thread or a thread synchronised with the audio thread. Very good to know ! -Michael ---
**Author:** ![xenakios](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/xenakios/32/4047_2.png) [@xenakios](https://forum.juce.com/u/xenakios)\ **Post date:** [February 21, 2022, 7:07pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/31 "2022-02-21T19:07:43Z")
> [@mschnell](#): > > ?? with the VSTi plugins I use, most relevant parameters are provided as well in the UI as with DAW parameters as with Midi CCs. (But of course not ALL parameters). > -Michael Again, I am talking mostly about _effect_ plugins, not instruments. Instrument plugins of course regularly have all kinds of MIDI CC control support built-in. ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 21, 2022, 7:08pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/32 "2022-02-21T19:08:58Z")
> [@daniel](#): > > And Midi CCs lack another property: an audio parameter knows how it should interpolate between two control values, which is not the case for midi CCs afaik. Hmm. Having the DAW interpolate (smoothen) the parameter move would result in an insane count of micro-changes, IMHO the plugin audio algorithm is supposed to do this according to it’s needs. -Michael ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 21, 2022, 7:10pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/33 "2022-02-21T19:10:04Z")
> [@xenakios](#): > > Again, I am talking mostly about _effect_ plugins, not instruments. Why ? IMHO there should not be a relevant difference according to the API. IMHO, an effect plugin is just an instrument that (usually) ignores Midi Note messages, while an instrument is an effect that (usually) acknowledges them abd (usually) ignores audio input. Moreover both might or might not send Midi messages, which is why some additionally define the plugin class “Midi Filter” that (usually) ignore audio in and don’t send audio out. To me it does not make any sense to differentiate this as “classes”. -Michael ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 21, 2022, 7:12pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/34 "2022-02-21T19:12:54Z")
> [@daniel](#): > > Plus the point @kamedin brought up, that in the default VST3 scenario the processor and the editor are separated, potentially even reside on physical different machines. Why is this a problem ? Of course parameters need to be sent to and fro between algorithm, GUI, DAW parameter interface DAW Midi (CC) interface (and e.g. with Reaper secondary “embedded” GUI). I just did an example program exactly for this. -Michael ---
**Author:** ![kamedin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kamedin/32/11711_2.png) [@kamedin](https://forum.juce.com/u/kamedin)\ **Post date:** [February 21, 2022, 8:04pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/35 "2022-02-21T20:04:09Z")
I just meant that in VST3, parameter changes are communicated separately to the UI and the processing callback, and the synchronization is done _by the host_, not the plugin. We [already talked about it](https://forum.juce.com/t/notifying-host-about-audioprocessorparameter-changes/48462/48). The problem with respect to the current implementation is that, in VST3, the current values for the UI thread and the audio thread can be different, as any change will propagate separately to each one. They’re not a single atomic accessed from both sides, they’re two separate values accessed from each thread exclusively. ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 21, 2022, 8:28pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/36 "2022-02-21T20:28:38Z")
I did not see this (explicitly) in my sample project. I do internal synchronization between GUI, algorithm parameter (and second GUI), and external synchronization from this to DAW Parameter change in and out, and Midi CC in and out with no problems. But as this is just a proof of concept thingy, it might be that it’s not done in the most rigorous way possible. -Michael ---
**Author:** ![kamedin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kamedin/32/11711_2.png) [@kamedin](https://forum.juce.com/u/kamedin)\ **Post date:** [February 21, 2022, 11:56pm UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/37 "2022-02-21T23:56:02Z")
I mean it’s a problem in the current implementation of parameter management in JUCE, unless it’s forced by how things work in AU or AAX. In JUCE a parameter value has a single source of truth for the whole plugin, but it doesn’t in VST3, and that’s a good thing. The JUCE wrapper discards any parameter changes coming to the process callback whose values have been set before on the UI thread, and we have a single parameterValueChanged callback for both UI edits and automation. This forces to resynchronize in the plugin, with atomics or queues. If the process callback received parameter changes synchronously as it actually does in VST3, I wouldn’t have to keep a lockless fifo or alternatively check all parameters with atomic loads. ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [February 22, 2022, 12:00am UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/38 "2022-02-22T00:00:00Z")
> [@kamedin](#): > > I mean it’s a problem in the current implementation of parameter management in JUCE, unless it’s forced by how things work in AU or AAX. I think you are perfectly right, and afaik AAX has that separation as well, and I wouldn’t be surprised if AU has it as well. It is a weird assumption that processing time and presentation time are identical. In practice they can never be thanks to the block based approach. The only counter argument is that for UI events the timing is way more coarse than a block anyway. But that argument falls apart, if the change is not from the UI thread. ---
**Author:** ![mschnell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mschnell/32/10827_2.png) [@mschnell](https://forum.juce.com/u/mschnell)\ **Post date:** [February 22, 2022, 6:45am UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/39 "2022-02-22T06:45:29Z")
> [@kamedin](#): > > , I wouldn’t have to keep a lockless fif Of course I did use a Fifo in the testing project. I did find this obvious, as different threads are used for the GUI and the algorithm. Maybe a dedicated support by Juce for parameter transfer might be nice. But I can’t come up with a dedicated suggestion right now. If somebody might want to take a look at the testing project, I can dig it out. -Michael ---
**Author:** ![asimilon](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/asimilon/32/4235_2.png) [@asimilon](https://forum.juce.com/u/asimilon)\ **Post date:** [February 22, 2022, 9:36am UTC](https://forum.juce.com/t/sample-accurate-parameter-automation/50277/40 "2022-02-22T09:36:47Z")
Funny this discussion popped up, was talking about exactly this with my colleague yesterday (without having seen this). We had basically the same conclusion: the argument that “we can’t support it because some formats don’t allow it” is completely erroneous; the formats that don’t support per sample automation would just report a single value per block. I’m curious about how much community backing there is for the idea that VST2 (and whatever the defunct pre-cursor to AAX was called) should just get dumped from JUCE. At what point do we realise holding back the whole framework just to maintain support for out-dated technology is a stupid idea? If you really need to support it use an older version of JUCE, it’s not like the users who _need_ VST2 support are running up to date OSes anyway. [Previous page](https://forum.juce.com/t/sample-accurate-parameter-automation/50277.md?page=1) [Next page](https://forum.juce.com/t/sample-accurate-parameter-automation/50277.md?page=3)