All modern plugin API’s like VST3, AU3, and Propellorheads SDK work this way. It’s simply a cleaner design, with less opportunity to shoot yourself in the foot.
Even if you are working with legacy APIs like VST2, it’s still good practice to keep your UI and DSP code cleanly separated in classes, and to minimize the interdependence between the two.
The talk by propellorheads Magnus Berger at the last ADC explains the advantages of employing ‘separation of concerns’ in audio plugins.
It was also real eye-opener for what is possible with a well-designed architecture. (spoiler - they converted a desktop plugin’s binary to run on an Arduino with a networked GUI and also to a ‘cloud’ DAW in a browser, to run on multiple operating systems, and to several desktop plugin standards, all with no modifications to the source code!). What they have already achieved comes very close to what SOUL is promising.
Juce however does not work that way and only does the minimal possible things to just get the involved plugin formats running. And no support for Propellerhead Rack Extensions. And maybe Juce really even shouldn’t do anything more anyway…
I was referring to the issue of having to concern ourselves with the alignment, padding, and size of types when sharing data between a GUI and processor that might be running on completely different processors/architectures.
It’s the same issues as when sharing data with a DAW via the plugin API that we already deal with. For example, updating a parameter value, or saving a preset that’s readable on multiple platforms.
The solution is either:
Use datatypes known to the DAW (e.g. ‘float’ parameters) and rely on the DAW to translate to the correct endianness etc depending on the platform, or
Manually ensure that any shared data structures conform to consistent padding, size, and endianness yourself, or
Share data in an agnostic format such as XML or JSON.
