Saved automation data does not respect VST3's parameter id

Description

Changing the order in which parameters are declared in the source code of a VST3 plugin changes the assignment of automation data to plugin parameters. According to this topic: ID for Parameter Automation - VST 3 SDK - Steinberg Forums, that should not happen: as long as the parameter ID’s remain stable, the order in which they are declared in code should not matter.

Reproduction

  1. Create a new renoise song.
  2. Assign a VST3 effect plugin to track 1. For the purpose of demonstration, I went with the “helloworld” plugin from the VST3 sdk.
  3. Set up some automation data for the plugin parameters. For this example, I assigned “11xx” to the plugin’s “Parameter 1” and “12xx” to the plugin’s “Parameter 2”.
  4. The song now should look something like this:

helloworld_original

  1. Save the song to disk and close Renoise.
  2. Change the source code of VST3’s HelloWorld example plugin: in PlugController.cpp, in the function PlugController::initialize, swap the order in which Parameter 1 and Parameter 2 are added to the plugin’s parameter collection. Recompile the plugin and replace it with the original HelloWorld plugin in your VST3 plugin folder. Alternatively, I uploaded a zip file containing 2 builds of “HelloWorld” (one with the original parameter order, one with the inverted parameter order) here: https://sjoerdvankreel.github.io/renoise_vst3_param_order_test/renoise_vst3_param_order_test.zip.
  3. Re-open Renoise and reload the song. Observe that pattern effect “11xx” is now controlling “Parameter 2” and “12xx” is now controlling “Parameter 1”. Since the parameter id’s (kParamVolId and kParamOnId) in the plugin’s source code did not change, I would expect “11xx” to still be mapped to Parameter 1 and “12xx” to Parameter 2. See screenshot below:

helloworld_inverted

Expected results

A plugin developer should be able to change the order of parameter declarations in source code, and as long as all parameter ID’s are stable, saved automation data should keep working.

Actual results

In this example, automation for the 2 parameters get “swapped”. Pattern effects that used to control parameter1 are now controlling parameter2, and vice versa.

1 Like

Agreed, it is quite a bug. Renoise should respect the VST3 parameter id. Hope it will get fixed in a next version :crossed_fingers:

1 Like

Hi!

This thing is really getting in my way during plugin development. Basically what happens is, each time I make some small changes to the plugin code, I have to re-setup the automation data for all demo tracks shipped with the plugin. I also noted that FL Studio behaves the same as Renoise (which I think is wrong), and REAPER behaves without problems. Can anyone from the Renoise team at least confirm or deny this is actually a bug?

-regards, Sjoerd