vst3sdk

Reaper is just as good as FL Studio or Logic Pro. VSTs are really your biggest hurdle. Depending on how they are compiled, they may rely on platform specific code. Most big plugin makers have VSTs for all platforms though and your license works on all. The pathway is there should you choose, one day. Linux is quite good now. That being said, I know a lot of niche plugins that some guy wrote that only works on windows because that’s all he/she has access to. Some 8-bit synth bitcrushers come to mind. Also Steinburg made VST 3 sdk open source so you have a path to a free music production studio. https://github.com/steinbergmedia/vst3sdk

The VST3 SDK has been available on GitHub since 2017. I think that's when they introduced the GPLv3 option. See https://github.com/steinbergmedia/vst3sdk

But you don't have only Linux, you have (and probably first) OSX and/or Windows and then Linux, and you need an API that works well in that case. Being an in-process dll/so plugin, while fraught with perils gets you to avoid other issues (state, health, restart, identity, etc.) Also sometimes you don't have a choice, but have to make a dll, for example: https://github.com/steinbergmedia/vst3sdk or https://ae-plugins.docsforadobe.dev/ and many others. Sometimes it's the only viable choice. (I wish most have used grpc/flatbuffers/whatever to communicate, but then every RPC call have to be checked/retried/handled, and or shared memory well handled, with (?) locks, etc. - not a trivial thing for someone who is deeply specialized in making a very good effect/renderer/etc instead of dealing with this extra complexity on top).

You have to use the steinberger SDK to make a vst https://github.com/steinbergmedia/vst3sdk But audio plugins come in many formats.

> What Cockos did with Reaper and their VST "extensions" is absolutely not part of Steinberg's conception of VST. I tend to disagree. What else is the purpose of the effVendorSpecific/effCanDo and audioMasterVendorSpecific/audioMasterCanDo opcodes? > two organizations could "define" an extension that uses the same integer value for the audiomaster callback Yes, this is indeed a problem. > LV2 uses URI's to identify extensions And VST3 uses COM like interfaces with GUIDs. I think it's just two different ways to achieve the same thing. > Do you know that the SDK Steinberg distributes for VST3 is larger than the entire Ardour codebase? :-) 99% of the VST3 "SDK" is just unnecessary cruft, the actual plugin interface is pretty small (although not as small as VST2). I've written a cross-platform VST3 host, and "pluginterfaces" is really all you

This is similar to the work done in winapi [1], com-imp[2] and my own tangential work on porting VST3 [3] to Rust [4] I'm really glad MS is doing this. What needs to be a bit clearer to me is how they maintain ABI compatibility under the hood of MSVC for COM interfaces (which uses the vtable layout of an inherited class) and how that's compatible with MinGW/GCC stacks on Windows, mostly what can break it. I got stuck porting VST3 with multiple inheritance, and it was a headache trying to reverse engineer the appropriate struct layouts for COM implementations. [1] https://github.com/retep998/winapi-rs/blob/0.3/src/macros.rs [2] https://github.com/Connicpu/com-impl [3] https://github.com/steinbergmedia/vst3sdk [4] https://github.com/m-hilgendorf/cli-host (sorry for the messy code, it was a weekend of hacking away trying to host a VST3 in pu

This happened https://github.com/steinbergmedia/vst3sdk ;) But still, I see no reason to use it over LV2 or even LADSPA.