VST3 Weirdness, Voxengo and Auburn Sounds

[pough]

I don't know what it is about VST3, but it seems to be where all the weirdness is. The VST3 versions of Voxengo and Auburn Sounds plugins are being affected by MIDI CC data. I first noticed it when Waveform's looping (sends a value of 0 to two CCs) caused Voxengo EBusLim to blow my ears out.

***
Easy test: Add the VST3 version of Voxengo SPAN (free!) to a track. Open the interface. Send any MIDI CC data. It changes the metering type.
***

Most Voxengo plugins just change the bypass status. SPAN changes the metering type. EBusLim changes the Input Threshold, which is terrible for when you want your ears to not bleed.

Auburn Sounds' Renegate and Graillon2 also have this issue. I haven't been able to find any other plugins that have MIDI CC mysteriously mapped to a parameter.

Waveform 11.5.18; Windows 10

I contacted Voxengo who say, "This isn't programmed into EBusLim, so it must be coming from the audio host application."

[suganthan]

I can recreate the same bug here when I insert SPAN VST3 here,

vst3 voxengo bug waveform.PNG

The bug goes away if I insert any plugin(on any track).

Waveform: 11.5.18; Windows 10

[pough]

Thanks for the confirmation! I also contacted Auburn Sounds. Unlike Voxengo they will look into it.

[pough]

Just a note here to say that Reaper was having a similar issue and their latest update includes this:

fix incorrect parameter setting in response to MIDI CCs

So I guess instead of the plugin incorrectly mapping MIDI CCs to a parameter, it's the host.

[pough]

Auburn recently updated all of their plugins and the new versions do not have this issue. Voxengo plugins still have it. The stomp/clap/snap plugins made by Boz Digital also have this issue, but not any others.

I've noticed that it's the first exposed parameter. In most Voxengo plugins it's the Bypass. (Sadly, it's the input threshold in EBusLim.)