Request for clarification on VST3 parameter automation update frequency

Help, Support & Bugs
1

Hi!

I’ve noticed parameter automation in Renoise is not nearly as smooth as in other DAWs (tested Reaper, Bitwig and FLStudio).

Scenario is the following:

Load Surge XT into Renoise, create a single pattern of length 32, BPM 120, LPB 8, play a single C4 note from the start (Surge defaults to saw osci). Add an instrument automation control that varies Surge’s filter cutoff from 0 to max in those 32 lines. So +8 per line. The resulting changes in filter cutoff are audibly stepped. I am running at 48khz with the default 12-ticks-per-line, but varying any of those 2 doesnt seem to help much.
Is this expected behaviour? And if so, why? Reaper and Bitwig, on a similar simple demo, perform filter cutoff modulation absolutely smooth. Sorry if i’m missing something.

So really how often are automated vst3 parameter updates supposed to be sent to the plugin processor?

For some in-depth details: I’m developing my own VST3 plugin (just used Surge as an example because anyone can download it) and these are the results I’m getting when I am debugging automation events in my own synth:

  • Reaper with 160 block size, 48kHz gives me 1 update per block, so 300 per second
  • Renoise with 480 block size, 48kHz gives me 1 update each 8 (!) blocks, so only 12.5 per second
  • Renoise with 128 block size, 48kHz gives me 1 update each 20 (!) blocks, so only 18.75 per second

TBH i have not debugged Bitwig nor Fruity but they do sound smooth, so I am assuming loads of parameter updates in those, too.

Now I know all of this can in theory be solved with internal parameter update filtering in the plugin (actually tried that, sounds smooth with an 150ms or-so low-pass), but that’s an additional 150 ms of latency. Also surely it cannot be the case that a somewhat mainstream synth like Surge behaves so radically different in Renoise vs any other DAW just with default settings?

Any insights and/or clarification greatly appreciated. Or even better please just tell me that i’m wrong and i messed up somewhere:)

Still loving Renoise so thanks once more for a wonderful product.

2

I don’t know the details, but I assume that the parameters are updated at tick rate?

Bitwig is really neat in this regard, everything is most precise, nailed at sample rate. No random results here :laughing:

I actually recommend to not use Renoise automation or meta devices for volume modulation. There are better alternatives like Devious Machines Duck, triggered thru a vst3 sidechain signal. There you have sample accuracy again.

I would be interested in some definite answers of the developer about this topic, too.

1 Like
3

It probably sounds stepped because either you recorded the automation changes across pattern lines in the pattern editor or set to points in the automation editor?

I think Renoise defaults to points when realtime recording inside the automation editor. After you have recorded the automation, change from points to either lines or curves and the automation will sound smoother.
image

1 Like
4

@Jonas

Thanks a bunch for that!

Been over a decade renoise user and never took the time (my bad) to look into the automation curves. Honestly didnt even know they existed. Although, i never record automation, i just punch it in. That’s why i use a tracker in the first place! Just go 0x00 - 0xff, interpolate column.

Anyway, this is NOT smooth:

renoisenotsmooth
renoisenotsmooth1920×1080 285 KB

And this IS smooth:

renoisesmooth
renoisesmooth1920×1080 277 KB

Thanks for this. It’s not my preferred way of working, but definately good to know the option exists.

1 Like
5

yes, this is to be expected when you set the automation in the pattern editor since every line represents a value change. Depending on the bpm, lpb & pattern length resolution you could improve it sounding less steppy though (use tools like; GitHub - mogue/renoise-pattern-zoom: Renoise tool to expand the lines per beat and repositioning the relevant data. to easily expand patterns across a song, so you spread the same music across more pattern lines), but I guess this still won’t sound as smooth as simply drawing in a line in the automation editor.

Also imo it is worth checking out some of the automation tools for playing around with shapes in the automation editor, fun way of quickly generating stuff which would otherwise require a ton of manual editing;

1 Like
6

@Jonas

<< this is to be expected when you set the automation in the pattern editor since every line represents a value change

This is exactly what i’m trying to clarify!
Lets say i have 4 lines with automation 0x0, 0x40, 0x80, 0xc0.
Also for simplicity lets make it 4 ticks per line instead of the default 12.

I see 3 options:

  1. renoise sends updates per line, i get 0, 0.25, 0.5, 0.75 => 4 times
  2. renoise sends updates per tick, i get 0, 0.0625, 0.125, 0.1875, 0.25, 0.3125, etc, => 16 times
  3. either 1) or 2) but with interpolation

Unfortunately neither (2) nor (3) seem true, and we’re really stuck at (1).

On a 32 line, 16 ticks-per-line pattern, I would indeed expect 16*32=512 parameter updates. That’s plenty more than enough for a plugin to reconstruct a smooth signal internally without significant lag.

That’s not what happens in renoise though!

Given the above mentioned example of 32 lines, 120 bpm = 2 bps, 8 lpb, 16 ticks-per-line, this works out to 2 seconds of audio.

If renoise sends updates per line, I get 32 in 2 seconds (not so good and i suspect this is whats happening). If renoise sends updates per tick, I get 256 in 2 seconds (easily good enough).

BTW, comparing those numbers with my first post, it really seems renoise does automation data per-line, not per-tick, and also does NOT interpolate lines (let alone ticks). An obvious workaound, then, is to increase the pattern size and just have more lines. Not the end of the world, but annoying. Growing up in the 80s/90s i still love me some manual punch-it-in-automation haha. Would be a shame if that’s ultimately inferior to mouse-drawn curves.

@taktik sorry tagging you again but I don’t know of anyone else who knows the details of this – what is exactly happening, under the cover?

  • Does it update per line?
  • Does it update per tick?
  • Does it interpolate, from the host side?
7

@ffx

<< but I assume that the parameters are updated at tick rate

That’s what I first thought, but see above.

<< Bitwig is really neat in this regard, everything is most precise, nailed at sample rate

Not really at sample rate. I observed bitwig to send updates for CLAP modulators every 64 samples. I would be surprised if that’s any different for either CLAP automation or VST3 automation. Still, @48kHz that works out to 750 (!) updates a second, which is easily more than enough to reconstruct a smooth signal inside the plugin.

<< I actually recommend to not use Renoise automation or meta devices for volume modulation

So as it appears renoise does smooth curves already, just not within the pattern editor!

<< I would be interested in some definite answers of the developer about this topic, too

As do I. See above. Fingers crossed :slight_smile:

1 Like
8

Ah yes, I remember that Urs mentioned similar one time in the KVR forum. Or maybe it was in the discord channel of the Surge devs, namely Bacon Paul. I also remember that the goal was sample accuracy though. And wasn’t the recent Cubase version claming to provide sample accurate automation, too? I doubt that VST3 is more capable than CLAP… Lot of confusion for me here…

1 Like
9

  • Pattern automation and Points mode in graphical automation are not interpolated. Parameter changes are simply sent out at the point specified in the pattern, sample accurate.

  • In graphical Line or Curve automation, points in the automation are sent sample-accurately, as in Points mode, and values in between are interpolated and sent on each “tick”.

A “tick”'s duration in samples is defined via the sample rate, BPM, LPB and TPL settings in Renoise.

tick duration in samples = (SR * 60.0 / BPM / LPB) / TPL

So e.g. at TPL 12, LPB 4, BPM 120, and a sample rate of 44100 Hz a tick and thus the interpolation step is 459 samples.

To schedule parameter automation for plugins, the plugin’s processing block size must be adjusted so that parameter changes are applied at the desired time before each beginning of a processing block. This causes quite a bit of overhead, as smaller processing blocks cause more overhead in general. For this reason every host out there will do some quantization here. In our case its ticks, other hosts will use different values.

The VST3 protocol supports sample-accurate scheduling of parameter changes in plugins. But we do not currently use this because I think most plug-ins out there discard the sample time anyway. Especially if they are ported from a VST2 plugin.

1 Like
10

@ffx

<< I doubt that VST3 is more capable than CLAP… Lot of confusion for me here…

I’ve been working for over 4 years with the both of them so i do have some opinions on the matter. I do think CLAP has some killer features that really make it stand out from VST3, but sample-accurate is not one of them. Both do sample accurate automation (i.e. scheduling parameter changes midway through a processing block) just fine.

For me, what really sets CLAP apart are:

  • Full access to raw midi data inside the plugin
  • Ability to join in on the host threadpool (ie all plugins inside the host as well as the host itself share a single multi-core worker task pool, instead of “to each his own” - should give the DAW way more opportunities in deciding how to allocate CPU cores, and frees the plugin dev from having to do so)
  • Non-destructive automation (clap calls it modulation). Allows you to run f.e. a host-provided LFO against any plugin parameter of your choice without messing up the patch state. Bitwig goes really crazy with this.
  • Per-voice modulation: allows any host-provided modulator to target individual voices in a polyphonic synth. E.g. with partially-overlapping voices in a chord progression or whatever, allows each synth voice to have it’s own virtual copy of said host-provided modulators.

There’s probably more stuff i haven’t even looked into yet, but for me, those are the big ones.

Anyway, if you want to know more of this stuff i’d be happy to clarify, just pm me. But note i’m by no means an expert on the matter – just a user of both API’s like so many other plugin devs.

BTW also nice to see BaconPaul’s name popping up over here. He’s helped me out a lot over the years.