Cabbage Logo
Back to Cabbage Site

Bug with presets and plugin parameter state (in VST)

Hello guys! I found a bug!

Cabbage version: 2.1.04 (64bit)
DAW tested: Reaper v.5.965
Windows 7

Steps to reproduce:

  1. Export following code as a vst or vst3 plugin (behaviour in both it’s the same)

    form caption(“presettest”) size(250, 250), colour(0, 30, 56), pluginid(“presettest”), guirefresh(10)
    rslider bounds(20, 108, 100, 100), channel(“pitch”), range(-500, 500, 0, 1, 1), text(“PITCH”), trackercolour(122, 139, 168, 250), outlinecolour(122, 139, 168, 250), textcolour(122, 139, 168, 250), trackerinsideradius(0.15), style(“modern”)
    combobox bounds(124, 52, 90, 30), , , , fontcolour(122, 139, 168, 250), channel(“preset”), populate("*.snaps") channeltype(“string”) value(“1”) colour(0, 30, 56, 255) fontcolour(122, 139, 168, 250)
    filebutton bounds(24, 52, 90, 30), colour:0(0, 30, 56, 255), colour:1(0, 30, 56, 255), fontcolour:0(122, 139, 168, 250), fontcolour:1(122, 139, 168, 250), channel(“but1”), text(“Save”, “Save”), mode(“snapshot”)

    -n -d ;-n -d -+rtmidi=NULL -M0 -m0d ; Initialize the global variables. ksmps = 256 nchnls = 2 0dbfs = 1

    ;seed 0

    instr 1

    kshift chnget “pitch”

    a1 inch 1
    a2 inch 2

    fftin1 pvsanal a1, 1024, 1024/4, 1024, 1; fft-analysis of file
    fftin2 pvsanal a2, 1024, 1024/4, 1024, 1; fft-analysis of file

    fshift1 pvshift fftin1, kshift, 50, 0; shift frequencies
    fshift2 pvshift fftin2, kshift, 50, 0; shift frequencies

    ainr1 pvsynth fshift1; resynthesize
    ainr2 pvsynth fshift2; resynthesize

    outs ainr1, ainr2


    ;causes Csound to run for about 7000 years... f0 z

    ;starts instrument 1 and runs it for a week
    i1 0 [606024*7]

  2. Change pitch parameter few times and save a new parameter each time.

  3. Turn daw into automation recording mode and hit play

  4. Start sweeping thru presets

  5. Result: Presets change doesn’t result in a plugin parameter change

Repro: 10/10 (2.2 MB)

Here is a video showing above issue ^^

And csd file
PresetBug.csd (1.6 KB)

Eek, that’s a good one! I’ll take a look and see if I can sort it out. Leave it with me for a bit.

Sorry for the delay in getting back to you, but I just took a look at this. It turns out it’s not a bug, as it was never meant to work like this, yet I can see why this might be useful. Leave it with me. I have a few ideas on how I can make it work.

I spent some time on this and it seems that it will not be possible to implement without some serious rewriting. The problem is that once the preset system becomes a parameter, automatable via a host, users will no longer be able to change the number of presets on the fly as VST plugins can’t dynamically modify parameter ranges. So you’d have a situation where you would need to close the plugin and remove it from a track each time you wish to save a preset. That’s not very workable.

If you wish to automate presets you’ll need to implement it yourself in Csound code. It will be a bit of work, but once it’s done you can use it across all of your plugins. Let me know if I can help. It was a nice idea, but will mess up the preset system completely if I implement it.

Thank you Rory for taking your time on this!

Sorry for the late reply on this.

It’s not really about automating preset param, it’s very other thing -> when you actually change a preset you change other parameters, right? So, I enable writing automation here - and when I change parameter by knob the automation gets recorded, but when I change parameters by preset change DAW doesn’t know that other parameters (not presets itself) change happend, so they don’t record it.

Using my above code example to be more clear and precise:

  1. Pitch knob change -> leads to “pitch” param change, the DAW knows about, and records automation as well for “pitch” param
  2. Preset change -> Pitch knob change -> “pitch” param doesn’t change and the DAW doesn’t know about it at all; if you also will switch the view from UI to params, you’ll notice that plugin params are not updated while changing presets.

Ah, Ok, I see where you’re coming from now. That’s indeed odd. Sorry for not getting this :joy: I’ll take a look at it again during the week.

Hi @MartinS9001. I have this working now, although only for standard widgets like sliders buttons, combo, etc. It still need some testing but it’s looking better than before. Azure DevOps is having some problems at the moment so my current changes aren’t being built but it should be resolved soon. I’ll send you a link to a beta version once it is done.

If you click the artifacts link on the following page you will get new installers for both OSX and Windows. Let me know if they work Ok for you.

Thank you Rory, I’ll check it soon!

1 Like