I'll revisit the documentation, and point to excepts, if and only if there's a paycheck involved. I want six figures. Eight if you pay in yen.
Barring that, I'll just summarize from memory. The way they write C++ is characteristic of the days when everyone could agree that Objects Are The Future™ and we could all have flying cars if only we could orient our objects hard enough. Every single thing I found objectionable was an idiom I've seen in other codebases, though maybe not all at the same time. In other words, this was all normal once. Just like bloodletting.
There are a whole bunch of custom classes that wrap C++ primitives. For example, there are several variants of "UString" for wrapping C strings. I didn't look up what exactly this is, but my guess is that the "U" stands for "Unicode" and that the encoding they use is the same obsolete UCS-2 preferred by Windows. Alternatively, maybe it's just a reference-counting thing, since this seems to be C++98 and they didn't yet have basic tools such as fire.
(Actually I might have just convinced myself it isn't for reference counting. It looked like several of the variants were fixed-size buffers, which implies stack allocation. Don't correct me. I don't care.)
There is a preprocessor macro (or perhaps a constructor) to convert C string literals to UString objects. It gets used a lot, because all the functions and methods that take string arguments actually take UString arguments, because I guess some of the property lookups might be dynamic and everything has to be an object anyway.
There are also preprocessor macros for other things. Now, the LV2 format is sometimes criticized for the way it exposes plugin metadata tables. I think the way they do it is fine, actually, at least compared to this. There is an entire preprocessor macro DSL for declaring your plugin's interface. It looks like it builds the metadata table and also generates a bunch of code that will actually be compiled into methods of your class. I didn't stop to check whether it's used only for the main plugin class, or for every host-facing class you create. The syntax of this DSL reminded me a little of the source code for the original Bourne shell, and also GObject. But in an uncanny way. Like maybe they went through a teleporter together and came out merged into one body with too many limbs, and now they're wearing a trenchcoat and trying to convince you they're just two kids standing on each other's shoulders. At any rate it's definitely something I didn't want to run into today.
I'm pretty sure I also saw some "annotation-only" keywords, #DEFINEs that the preprocessor just removes during compilation, because they only exist for the sake of IDE tooling. You see those a lot in old Windows code and stuff that has to interface with Pascal. I don't hate these per se. They're just kind of annoying, a reminder of how deeply the codebase is married to all this macro mayhem.
I am pissed off by how many raw pointers I saw in random bits of example code. Do the method definitions even describe the ownership implications of whatever's being passed around? Why go to the trouble of writing all these wrapper classes for everything and then expose raw pointers? Come on.
The part that broke me was a page that starts with a blurb about freeing us from the tyranny of MIDI (or something grandiose like that) and then immediately drops a bunch of example code that's obviously mostly ceremony. You have to do so much setup to call into the part of the API you're actually trying to talk to. Again, something I've seen a million times. Remember Java? But at the end of these piles of code, there was a comment saying something like "See? It's that simple!" And that's when I genuinely started to suspect that at the end of the day, this whole VST3 thing is just an out-of-control prank.
