I don't use D (I make my audio stuff using Rust) but it's always good to see new audio libraries/tools.
Slightly off-topic, I'd love to see an open project for audio plugin specs. VST and AU are managed by private companies and have a history of extremely poor documentation. For anyone who tried to code audio stuff at least once, it's a real pain. Audio is already hard in itself.
(Don't even get me started on the bugs around AUv3…)
I hear you on that. It is especially embarrassing that despite the callbacks being essentially the same since the '90s, there are still ~5 APIs to do the same thing, and all of them are this ugly. I wonder how LADSPA and LV2 look...
LV2 at least has units, so you don't need to use some arbitrary rule to convert your Hz, dB, octave, and other units to a 1.0f > float > 0.0f and then that float maybe into an integer.
Putting aside plugin/processor APIs for a moment, I think platform APIs are even worse. I mean, PortAudio, whose namesake is portable audio, does not include a functioning PulseAudio sink, and doesn't function correctly on most GNU/Linux systems of the last decade.
After testing the native Reaper build for Linux it really looks like something big is happening over here, but if I recall correctly, in the past Steinberg (the company behind the VST standard) has been extremely hostile to any Open Source implementation of their libraries etc. I admit having been under a rock for some time in this field, so could anyone summarize what changed and if there are any caveats/traps for developers willing to write native VST plugins for Linux?
You still need to agree to the VST SDK terms to use this.
Note that there exist other bindings for VST in Rust, Java, .NET, Delphi... you _have_ to translate part of the SDK to be able to use it from another language that C++.
In essence this is not different than jVSTwRapper or VST.NET, both of which still exist.
IIRC the VST SDK terms forbid the redistribution of the SDK itself ; which is partly what makes it GPL-incompatible. Whether this restriction applies on translated versions is legally grey.
I wouldn't say "extremely hostile", more "unbothered" that their licensing conditions don't suit open source projects. They have tried to open things up a bit, but only for VST3 not the obsolete-in-their-opinion-but-not-anyone-elses VST2 SDK.
There is an obvious reason: implementing a whole new plugin format is harder than just implementing a graphics backend for VST2. LV2 or LADPSA is only useful on Linux IIRC and that's not necessarily a huge audio market.
Just a note that JUCE is now free for indie developers if your yearly revenue is less than $50K per year. It just adds a JUCE logo for a few seconds the first time your plugin window opens.
Also, it looks like JUCE is available for a one-off fee, if you don't like the monthly subscription. $700 once on an annual revenue of $200K seems reasonable, especially since there's the free-with-splashscreen tier to help you earn that first $700.
Or as an alternative DPF https://github.com/DISTRHO/DPF which at least supports JACK and LV2 (the pull request for it for JUCE has gone unmerged for years :( and no additional license restrictions
Slightly off-topic, I'd love to see an open project for audio plugin specs. VST and AU are managed by private companies and have a history of extremely poor documentation. For anyone who tried to code audio stuff at least once, it's a real pain. Audio is already hard in itself.
(Don't even get me started on the bugs around AUv3…)