VST3 SDK could need some improvement...

DSP, Plug-in and Host development discussion.
User avatar
S0lo
KVRian
940 posts since 31 Dec, 2008

Post Thu Oct 07, 2021 7:56 am

Markus Krause wrote:
Thu Oct 07, 2021 4:16 am
I want to give some attention on this:

https://github.com/pierreguillot/FTS

It allows building VST2 compatible plugins without having a VST2 license signed by Steinberg
Unfortunately, It's GPL licensed, so if I use it I have to GPL my code too. Which means I have to release my code.

User avatar
Erich.Pfister
KVRist
203 posts since 24 Jul, 2020

Post Thu Oct 07, 2021 11:14 am

DRMR wrote:
Wed Oct 06, 2021 4:23 pm
reaper, ardour, carla, mixxx, zrythm, (the list is only growing). just because hosts support multiple plugin formats doesn't mean you need to exclude any ;)

Erich.Pfister: nice that you are looking into DPF. I'm using it to build audio plugins in hvcc and was quite easy to create the wrapper. And now I can make cross platform lv2, vst2 (and soon vst3) plugins with ease (the old implementation was based on the deprecated steinberg sdk). It's also nice to be able to have a liberally licensed format that doesn't get in the way of what you as a developer may want to use it for. No signing of any commercial license deals or whatever. Just use the code as you see fit and give back if you can!

DRMR - I'm planning on contributing. I have a bunch of buggy but usable boilerplate for VST3 that mostly overlaps what DPF/DISTRHO is doing, but I have a sneaking suspicion that I've probably implemented something that they haven't yet. I'll basically extend DPF as I need to and give back whatever extensions I create. I like the idea of sharing and working collectively on open source frameworks while maintaining closed source products built from those frameworks.

User avatar
Erich.Pfister
KVRist
203 posts since 24 Jul, 2020

Post Thu Oct 07, 2021 11:22 am

S0lo wrote:
Thu Oct 07, 2021 3:26 am
I think Steiny is unknowingly doing JUCE a big business favor by making VST3 unapproachable.

In the end. Survival is for the fittest. Let's see what the next 10 years would do to VST3. I think the format will be still there and every where. But the majority of the code out there wouldn't be written directly for it. But rather on a framework like JUCE, IPLUG etc. Eventually JUCE could it self be turned into a new native format.
This is literally the main reason I don't want to use JUCE. I don't like that it enables the VST SDK to be so awful. I also don't like that it enables certain DAWs to be nonconforming. By using this somewhat amorphous and constantly changing library that accounts for new products as they are added to the scene, you're putting a lot of power into one library. I don't mean this to imply that anyone at JUCE or Steinberg or any of the big DAW companies have are acting in bad faith, just that I don't want to have to trust anyone. I also didn't like one of Jules' speeches where he talked about how we're all wasting our time writing oscillators and filters and all audio primitives should just be cookie cutter classes. Part of the fun of this line of work is reinventing the wheel, and sometimes that only happens when things don't go smoothly.

User avatar
Erich.Pfister
KVRist
203 posts since 24 Jul, 2020

Post Thu Oct 07, 2021 11:28 am

Markus Krause wrote:
Thu Oct 07, 2021 2:00 am
Steinberg's VST3 SDK including the VST3 format is a complete mess. It was the most frustrating experience I had in 25 years of software-development.
Markus - I learned C++ in high school so that I could write VST plugins. I'm almost 30 now and I finally have a product. The product crashes constantly and has compatibility issues. I honestly thought I was a bad programmer - imagine if your only reference for success as a programmer was working with the VST SDK. I totally understand where you're coming from!

User avatar
quikquak
KVRian
788 posts since 6 Aug, 2005 from England

Post Thu Oct 07, 2021 11:35 am

With juce you don't HAVE to use any of their DSP code, I don't go near it myself, but it's great for beginners. Their SIMD functions work rather well though.

Angus_FX
KVRAF
4735 posts since 18 Jul, 2002 from London, UK

Post Fri Oct 08, 2021 2:11 am

I want to give some attention on this:

https://github.com/pierreguillot/FTS

It allows building VST2 compatible plugins without having a VST2 license signed by Steinberg
Difficult to say whether this would withstand a legal challenge. There are still some Steinberg type names in there for example.

I applaud them for doing it anyway, though.

More time has now passed between the release of VST3 (in 2006) and the present day, than passed between the release of the MIDI spec and VST1 (in 1997), and still ~nobody likes it or is willingly adopt it. ("Under duress, because lawyers blocked all the other routes" does not count as willing).
This account is dormant, I am no longer employed by FXpansion / ROLI.

Find me on LinkedIn or elsewhere if you need to get in touch.

User avatar
Erich.Pfister
KVRist
203 posts since 24 Jul, 2020

Post Fri Oct 08, 2021 1:14 pm

quikquak wrote:
Thu Oct 07, 2021 11:35 am
With juce you don't HAVE to use any of their DSP code, I don't go near it myself, but it's great for beginners. Their SIMD functions work rather well though.
SIMD is where it's at - I've been doing my best to hint to the compiler via loop topology that it ought to use some SIMD instructions. I'm not quite at the point where I want to look at assembly, but once I'm in my final optimization stage, I'll see how much is actually getting rolled into SIMD calls. I'm considering releasing binaries to target different extension sets. I would love to try and tap into what crypto mining is doing with graphics cards - there's a lot of latency there but you could feasibly run concurrent algorithms with a handoff to graphics card. Think of a reverb where the first 50ms of tail are processed on the CPU but the remaining 3 seconds or so are processed on the graphics card. Anyway, SIMD is pretty cool - would love to utilize it even more.

User avatar
Erich.Pfister
KVRist
203 posts since 24 Jul, 2020

Post Fri Oct 08, 2021 1:25 pm

Angus_FX wrote:
Fri Oct 08, 2021 2:11 am
More time has now passed between the release of VST3 (in 2006) and the present day, than passed between the release of the MIDI spec and VST1 (in 1997), and still ~nobody likes it or is willingly adopt it. ("Under duress, because lawyers blocked all the other routes" does not count as willing).
So much of our modern world is subject to regulatory capture and rent seeking - at least we have a shot at cleaning up this industry.

User avatar
Erich.Pfister
KVRist
203 posts since 24 Jul, 2020

Post Fri Oct 08, 2021 7:38 pm

This is my desktop background right now. In a world where XML and JSON exist, this is clear and obvious anti-competitive behavior.

Image

User avatar
Music Engineer
KVRAF
3979 posts since 8 Mar, 2004 from Berlin, Germany

Post Fri Oct 08, 2021 8:58 pm

"VST 3 Preset File Format Definition"? ...yeeeahh....no! looks they are really deliberately making things much more complicated than they need to be. i'm glad i'm using juce. ....and my own (xml-based) preset system.

rafa1981
KVRian
594 posts since 4 Jan, 2007

Post Fri Oct 08, 2021 10:07 pm

WRT SIMD, I went the route of using the compiler's (clang-gcc) vector types directly.

My rationale for doing so was:
-I use Clang for all platforms already, as I crosscompile my Windows binaries on Linux. It is the compiler with the best auto vectorization.
-The compiler clearly sees what is going on when optimizing.
-Direct porting to all architectures is possible.
-Wrapped shuffle.
-Ternary operator available.
-DSP code clear of JUCE dependencies (no lock-in).

The only drawback is that as the vector sizes are defined as attributes, it is not possible to do template specialization with them, but it can be made to work.

Return to “DSP and Plug-in Development”