Merged plugin build, possibly bad idea

[Tremus]

@martinfinke This merged plugin idea is pretty neat, however I think I've run into an objective C name collision problem with the GUI code, which is messing around with the audio units. The problem manifests when a VST3 or CLAP plugin is already loaded in the process, then an audio unit is opened. It can result in the Audio Units GUI not loading at all (or the parameter list fallback), or worse, a crash. I've only tested this in Ableton, FL and Reaper, but in all cases I'm getting bad behaviour.

The simplest solution would be to simply undo the merged plugin build tricks, and return to compiling all plugin formats separately, each with different Obj-C class names.

An alternative and much tricker solution would be to make all plugin formats a thin shell that loads a single plugin containing all the objective-C classes.

Have you run into this problem before? What are your thoughts?

[martinfinke]

From what you describe, code like this seems suspicious:

CPLUG/src/cplug_extensions/window_osx.m

Line 242 in b8b964b

#ifdef CPLUG_BUILD_AUV2

In the merged plugin build, CPLUG_BUILD_AUV2 is always true at compile time. So if your VST3 or CLAP plugin runs this code, it will wrongly set the Window delegate even though it's a VST3 or CLAP.
So maybe this code should be checking CplugHostContext' type for CPLUG_PLUGIN_IS_AUV2 at runtime.
CPLUG_BUILD_AUV2 means "is AUv2 one of the formats we're compiling?" It doesn't mean: "Am I an AUv2?"

Also, because you named Obj-C name collision, CPLUG_AUV2_VIEW_CLASS must be unique in the entire process. Same for any other Obj-C names in the global namespace. Objective-C is different from C or C++ where, as far as I know, each DLL can bring its own definition of the same name.

I haven't run into this problem myself, but I haven't tested what you're describing…and also, the code I'm using has now branched away from CPLUG, with a lot of changes.

[Tremus]

No worries man. Cheers you're right about using state to check for AUv2 instead of the macro. That's a bug

I've run into objc name collision bugs this week, so I'm going to stop using merged builds in the short term, and perhaps move to the shell later.

BTW what changes have you made to CPLUG in your branched version? I'd love to hear what parts you changed & why? I'm always looking to improve and learn new things

[Tremus]

Add it turns out I fixed the AUV2 macro thing months ago, and the change is on the develop branch

[martinfinke]

Good to hear that it was already fixed 👍

BTW what changes have you made to CPLUG in your branched version? I'd love to hear what parts you changed & why? I'm always looking to improve and learn new things

I started by adding a lot of guard code against bad host behavior, such as calling functions on the wrong thread, at bad times, passing NULL buffer pointers, starting playback without first informing the plugin about sample rate / block size, and so on.
Looking at what e.g. JUCE is doing, I noticed what a minefield the plugin-host communication is.
Also a lot of things that the plugin side "is supposed to do" in AUv2's Property system (🙄). Like if the host uses SetProperty to store something, it must later be "returned" by GetProperty, etc.
Unfortunately a lot of this guarding has to be done multiple times in each plugin format backend (VST3, AUv2, AUv3, etc.).

And a parameter echo guard: If the host echoes back a parameter change, synchronously or asynchronously, the code prevents "echo loops" where the parameter change bounces back between plugin and host.
This is also needed when the host asynchronously echoes back an outdated value, e.g. via the audio thread event queue, while you're dragging a knob in the UI.
Same for the case where the host truncates the double parameter value to 32-bit float and echoes it back.

So the question is… 😆 Should something like CPLUG even do all of this, or should it just be a thin wrapper?
My personal thoughts on this:

1. If CPLUG is just a thin wrapper, then all the guarding and special-case protection is left to the plugin itself. Then I need another "unified guard layer", or else I would duplicate a LOT of guarding code in every individual new plugin.
2. A lot of guarding needs to be done immediately inside CPLUG itself, inside each plugin format backend. Because without guarding, CPLUG's own code would access NULL pointers, suffer from race conditions, etc. before it can even enter into the "unified guard layer".

This is just what I personally want/need in my projects, not the "objectively right answer". It's a big trade-off: The code became much bigger, and more "messy" in a way, with lots of "if (!x) then bail out gracefully".

I'll be happy to share anything you need to know, just ask 🙂

[Tremus]

These are all really good points. Which DAW truncates doubles to floats and echos it back? Which were the most troublesome DAWs in your opinion?

Parameter handling still remains a bit of a nuisance. The only troublesome DAW for me atm is Ableton, which echos back old values on the main thread while you're dragging values.

I was thinking of creating a kind of "unified guard layer" as a new cplug extension, similar to the windowing library. I've already got one in my private code which is working alright