Saved automation data does not respect VST3's parameter id

Help, Support & Bugs
1

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.

2 Likes
2

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
3

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

4

Agreed.

Renoise seems to rely on the parameter index only (just as vst2), but should map the parameters instead by id properly. Old song versions still could use the old behaviour. New songs need to save the parameter-id mapping inside active_preset_data or so. Then the order could be freely changed. I guess that would affect the automation mapping, too. Not an easy task, I assume.

Please at least expose the parameter-id a via the API to make it usable for export tools, etc.

Thanks for consideration.

5

Thanks for the bump. Beside my own spare time project there’s bound to be more plugs which divert the param id from the index, and it’s a shame Renoise can’t use them. Part of the problem is that JUCE plays by the VST2 rules even in VST3 mode, and since loads of plugs are JUCE plugs, Renoise (and i’m sure some other hosts, too) can get away with this.