Rust Audio

Plugins not displaying correctly as of Bitwig 2.5

@delu has brought up the issue that, as of Bitwig 2.5 (on both Mac & Windows), info data for plugins is not read.

On the left is a regular non-rust-vst plugin. On the right is a rust-vst plugin. Note how the parameters do not display properly, and how the title is blank.

@wrl brough up how this return value should read 0 for success. While changing that value does not seem to fix the above issue, perhaps something else similar down the line is causing the issue.

I will create a GitHub issue for this once I get out of work. In the meantime, feel free to postulate or discuss this issue and its impact here.

As discussed in Telegram, try defining your own can_be_automated(). It seemingly wasn’t required pre-2.5, but now it is – at least to show up in this little window thing and to draw automation in the arranger timeline.

1 Like

Should any changes be made to correct this issue in the repo itself, or should this simply be a footnote in the wiki somewhere? Is returning true for can_be_automated a Bitwig quirk, or just Bitwig adding some compliance for the VST spec that we should follow?

Not sure at the moment; I don’t have any other DAWs to test it on, so I don’t know how standard it is. :slight_smile:

I’ll have to dive into the spec sometime and see, perhaps @wrl knows as our resident expert?

I always return “true” for parameters able to be automated. I think the motivation for that feature was that plugins should be able to have “internal” parameters which are handled via the standard VST parameter mechanism and saved along with parameter state. In that case, if previous versions of Bitwig were allowing for automation of parameters marked non-automatable, that’s a bug on their part.

There’s some utility in having “private” parameters but imo just don’t expose them to the host at all. Have them managed internally in whatever model structure your plugin has.

1 Like