VST3 SDK fun

[Vokbuz]

It appears to be a nasty rabbit hole. It starts innocently with:
vstaudioeffect.cpp
vstcomponent.cpp
vstcomponentbase.cpp
vsteditcontroller.cpp
vstbus.cpp
vstparameters.cpp
but each one of those pulls in another pile of headers from all over the place. No wonder nobody has adopted it with open arms. I don't even know where to begin. I should be able to just copy my code over, for the most part, and stuff it into new methods with minimal translation. Not happening...

I could go on, but I won't. Still crabby over the crappy parameters stuck at 0.0 - 1.0... Useless...

vstaudioeffect.cpp and other files are optional. You may not use them. Is this some kind of hidden knowledge? Some files from pluginterfaces is all you need to make VST3 plugin. Even there, many files are optional, most plugins don't need them.

Also, since when does more files mean worse? Do you put code of your project in a single file just to keep less entities in your code base?

[xoxos]

Also, since when does more files mean worse? Do you put code of your project in a single file just to keep less entities in your code base?

mm that's a real toughie

if i were more of a bastard, i'd answer this in 500,000 words, as many of which being obscure vernacular or API references as possible.

obviously the solution is to start charging $5999 for the SDK to keep the self conceptualised entitled from soliciting distain and scorn from sensible persons who know all of these thnigs somehow.

[xoxos]

and yes, the source for universe synthesizer (ifft resynthesis) i recently added to my forum is about 500 lines in one document.

but that's a complicated synthesizer.

[BertKoor]

This all reminds me of Arthur C. Clarke's third law...

[xoxos]

it reminds me of complicity

[syntonica]

Meh. It reminds me of lazy programmers that can't organize their code properly. For some reason, the current thinking is, "More is Betterer." More files, more classes, more folders, have to link in every crappy new thing in (e.g. was, XML, which nobody did right to begin with, now is JSON, which is just key value pairs hint hint...) because it makes their manly programmer bits grow an extra size. Whole forests of useless, over-engineered garbage where a small tree is all that is required. Meh.

So, in general, yes, fewer files, fewer entities, and very well-organized.

[Music Engineer]

For some reason, the current thinking is, "More is Betterer." More files, more classes, more folders, ...

more is only better if less is more

[quikquak]

It takes time to type 70000 lines of code, more time means more pay!
Winning.

[S0lo]

“Everything should be made as simple as possible, but no simpler.” Albert Einstein.

[mystran]

With C++ in particular it isn't exactly uncommon for every 100 line source file to pull in 20MB or more of headers full of templates that need to be instantiated, compiled and often optimized separately for every object file just so that the linker can then pick one of those copies and throw the rest away.

What this means in practice is that one of the most effective ways to slow down your recompilation times is to split your code into multiple source files. Obviously it is usually easier to edit reasonably sized files rather than a single monolith, but other than that it can actually be counter-productive in terms of build-times (including incremental build times, paradoxically enough) to split related things that are likely to be edited together over multiple files.

Something like splitting every class into a separate header and a source file makes a whole lot sense if you assume that people are using editors with functionality matching notepad.exe, but nobody does that. We use editors that can understand the structure of the code, lookup definitions and navigate around the whole project and even system headers. Obviously it's nice to group related concepts together, but having fine-grained organization on the file-system level is simply not necessary and it just makes your builds slower, so why would you possibly want to do it?

[syntonica]

It takes time to type 70000 lines of code, more time means more pay!
Winning.

I'm supposed to get paid?

[syntonica]

Something like splitting every class into a separate header and a source file makes a whole lot sense if you assume that people are using editors with functionality matching notepad.exe, but nobody does that.

You'd be surprised the minimalism in editors programmers use.

Compilers do a good job with pre- and incremental compilation. No need to stuff all your classes into a single file. I've spent the last couple of years learning to trust my compilers (clang, gcc). As long as I write nice, clean code, they will compile and optimize with great efficiency.

I just see a lot of unnecessary classes, wrappers, with unnecessary reliance on third-party libraries. I still don't understand the Boost-love that goes around! Frankly, I only use C++ as C with the ability to stick my method into my struct--er, namespaces. I have a few convenience methods to handle some mathy stuff and some stringy stuff that are specific cases, but are far faster than the C/C++ general cases. I don't think I pull in a single C++ construct (string, vector, etc.) They aren't any slower or faster, per se, they just add another level of unnecessary complexity.

If I wrote software to control nuclear power plants, I'd be a little less cavalier and use the safety afforded in C++, but nobody is going to use my plugin to take over the world, let alone take over the computer. Not that they could.

[BlueprintInc]

Splitting code by logical units is the least thing I'd do. If it is good for later composition or sharing with others, I'd even split it into more tiny pieces. And it's great too being able to have different coders working on different parts without creating conflicts because it's all in a single file. Compiletime doesn't matter here. We hardly clean everything and build it from the ground again every 5 minutes. But each to their own.

Btw the work of plugin creators is special. Boost or std are general purpose libs. Of course they add complexity to cover a wider range of use cases...

[Music Engineer]

What this means in practice is that one of the most effective ways to slow down your recompilation times is to split your code into multiple source files. Obviously it is usually easier to edit reasonably sized files rather than a single monolith, but other than that it can actually be counter-productive in terms of build-times (including incremental build times, paradoxically enough) to split related things that are likely to be edited together over multiple files.

unity build systems to the rescue!

for those who don't know: the idea is to make one .cpp file that #includes all the relevant other, smaller .cpp files and exclude the smaller .cpp files from compilation and compile only the big master .cpp file that includes all the others. so, at the end, you have only a single compilation unit created from multiple .cpp files

[xoxos]

my compiler has never taken more than some fraction of a second to produce a full compile.

at a 5mb footprint and faster exe than the last vc++ i installed, i find it to be relevant.

but my code isn't the foundation of a modality of expression among an entire species.