Specific technical questions about VST3, and info for users

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

mystran wrote:
lorcan wrote:
Aleksey Vaneev wrote:Decoupling of UI and DSP was always a bad idea, it's good only from academic perfection point of view. Now we have to push megabytes of data between UI and DSP to draw spectrum analysis view.
AAX and AU do it too, I'm not sure you could say Apple and Avid are academic perfectionists.
At least one of the more popular frameworks (and I suspect this approach is also very popular among people who don't use frameworks), namely IPlug appears to handle this for AU (no idea about AAX, haven't looked at that) by having the GUI query for a custom property which is literally the pointer to the actual plugin object. Once you have the raw pointer, you basically give middle finger to the whole separation non-sense and just do it the more efficient way.

IMHO the big problem with ALL the plugin interfaces is that they were designed by idiots who thought they are supposed to dictate the internal architecture of the plugin rather than just providing an actual interface. The fact is, that's just not going to happen and the more you try to force it down the throat of the developers, the uglier the hacks you get as a result.
AudioUnit is worse than anything else out there in this respect. They do not even have a standard way to define variable-size properties to communicate data, so I had to use workarounds. I was actually trying to play a "good guy" and implemented AudioUnit GUI and DSP decoupling the "correct way" only to later understand that nobody needs it after multi-core processors appeared, so there's no need in the originally available "outboard" processing capabilities. I expect when Apple releases the ARM desktop processors we'll need to move to AUv3 forcefully, another can of worms.
Image

Post

mystran wrote: IMHO the big problem with ALL the plugin interfaces is that they were designed by idiots who thought they are supposed to dictate the internal architecture of the plugin rather than just providing an actual interface.
a bit harsh! let's not forget that our fellow devs are humans with feelings and certainly not idiots!... if you work for a company you don't necessarily have the freedom to make the API you would really like to make if you were doing it for a hobby, or the freedom to consult 3rd parties, and there are all sorts of other issues, and industry politics at play. AFAIK a lot of the AU and CoreAudio APIs are designed in part by James McCartney of Supercollider fame ... sadly Apple didn't hire so well in the documentation department

Post

i was just scratching my head over why midi learn didn't work in bidule with my copy of toneboosters' reelbus4...
turns out i only had the vst3 installed and i guess midi learn doesn't work with vst3? what a bummer... freakin' idjits over at steinberg....

Post

The COM bloat seems to be mainly because of the ability to handle shell plugins or multiple plugins within a factory.

//----for others Plug-ins contained in this factory, put like for the first Plug-in different DEF_CLASS2---

Waves Waveshell routines seem to have been an afterthought bolted onto vst2 but now the multiple plugins can be in a factory.

The COM bloat and the associated routines and the way of programming that's needed is overly complicated to get multiple plugin features IMO and quite a few seem to be saying that it's overengineered and not really needed.

I think that COM was chosen for multiple plugin features and probably also the Controller/Audio separation both of which are not needed by the majority of plugins, so the complication of COM is to provide features that most will not use and that's why the takeup of VST3 has been slow and why Steinberg is now forcing VST3 to be taken up whether someone likes it or not.

Post

hibrasil wrote: Tue Jun 12, 2018 12:50 am
mystran wrote: IMHO the big problem with ALL the plugin interfaces is that they were designed by idiots who thought they are supposed to dictate the internal architecture of the plugin rather than just providing an actual interface.
a bit harsh! let's not forget that our fellow devs are humans with feelings and certainly not idiots!... if you work for a company you don't necessarily have the freedom to make the API you would really like to make if you were doing it for a hobby, or the freedom to consult 3rd parties, and there are all sorts of other issues, and industry politics at play. AFAIK a lot of the AU and CoreAudio APIs are designed in part by James McCartney of Supercollider fame ... sadly Apple didn't hire so well in the documentation department
I'll edit your post to correct its misguided thinking.
That's fair! Let's not forget that our fellow devs are humans and certainly are idiots who make mistakes and suffer from biases and ignorance to degrees indeterminable! ...

If you spend the time to create an interface which is flexible while working for a company you don't necessarily have the ability to strictly limit the API built upon that interface to only the product features your company needs directly. With an abstract interface you might implement feature "A" only to have competitors adopt a superior feature "B" leaving your company in the dust with a rusty clunker of a product due to lack of design foresight.

It requires a large investment of highly skilled technical expertise and willingness to defend to the ends of the earth any position you feel is justified during likely scathing consultation and review with 3rd parties (AKA peer review.) It also requires the ability to admit when your position was wrong and extremely dedicated fervor to seek out the best possible solutions free from corner cases to ensure your work is free from obvious mistakes.

AFAIK a lot of the AU and CoreAudio APIs are designed in part by James McCartney of Supercollider fame ... sadly Apple didn't require a foreward-thinking designer who would document all decisions and research progress thoroughly in order to ensure this knowledge was disseminated freely to promote the progress of mankind.
FTFY.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.

Post

ah the Christmas spirit!

Fabian did a nice talk about this stuff at ADC ...

https://www.youtube.com/watch?v=swVqdbhfkkE&t=2325s

Post

Which honestly speaking feels extremely 2 + 2 = 5. It's an unfortunate consequence of a tiny niche market where honestly nobody is able to provide any genuine productive critique.

https://en.wikipedia.org/wiki/Varieties ... -criticism

Image
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.

Post Reply

Return to “DSP and Plugin Development”