Dplug for Developing VST Plugins on Linux | Hacker News Reader

Dplug for Developing VST Plugins on Linux

modernmetalproduction.com

67 pointsp0nce26 comments

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…)

> Slightly off-topic, I'd love to see an open project for audio plugin specs.

It already exists and is called LV2: http://lv2plug.in/ ; you may be interested in http://lv2plug.in/gmpi.html

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.

I'm curious about what do you use for audio with Rust?

I'm afraid my answer is disappointing: just Rust, with the necessary boilerplate to wrap the code in AU or to the audio interface...

There's a github org here:

https://github.com/rustaudio

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.

Actually last year Steinberg dual-licensed the VST SDK under GPLv3 : https://sdk.steinberg.net/viewtopic.php?t=282

Yeah, but as dspig mentioned above, this only applies to v3 of VST, which is almost nobody uses. We're all using v2.3/v2.4.

We are currently working on a resolution to this issue. Thanks for bringing this out.

what is your opinion on Vestige's reverse-engineered aeffectx.h ? (https://github.com/falkTX/dssi-vst/blob/master/vestige/aeffe...)

Can't be used because it's GPL and most plugin makers sell closed-source plugins. We actually have quite a lot of R&D in some algorithms.

Sure but for someone writing a GPL host or plug-in there's no problem to use it, right?

The VST SDK is dual-licensed with GPL so the black room implementation is now moot.

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.

This happened https://github.com/steinbergmedia/vst3sdk ;)

But still, I see no reason to use it over LV2 or even LADSPA.

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.

If you don't like that, GPL is still an option.

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.

https://www.juce.com/get-juce

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

Cool! JUCE is actually a very impressive framework and it makes developing for all the different platforms & APIs surprisingly easy.

Yeah I'm working with Juce myself, it's used in other amazing tools for Linux audio that are open source.

Ah I wasn't aware of that. It has been a year or so since I last used JUCE. Thanks for that info.

If anyone else is scratching their heads wondering what VST refers to:

https://en.wikipedia.org/wiki/Virtual_Studio_Technology

Reply on news.ycombinator.com