3 ms·

Great interview! What wasn't entirely clear to me is the conceptual difference between LV2 extensions and other plugin extensions: "Whereas with LV2, you can a

Great interview! What wasn't entirely clear to me is the conceptual difference between LV2 extensions and other plugin extensions: "Whereas with LV2, you can actually say: 'Here is the spec for this extension. And it's written down and this is how it works'. So I think this is a great thing and I don't think it'll go away." Isn't this merely a matter of documentation? See for example the REAPER VST 2.x extensions (which you've mentioned): https://www.reaper.fm/sdk/vst/vst_ext.php https://www.reaper.fm/sdk/vst/vst_ext.php With VST 3.x (which has a COM-like API) you can even add entire custom interfaces which the plugin resp. the host can query.

PaulDavisThe1st 6y ago
What Cockos did with Reaper and their VST "extensions" is absolutely not part of Steinberg's conception of VST. Because of this, there's no namespacing: two organizations could "define" an extension that uses the same integer value for the audiomaster callback, and there's nothing to resolve that except for one of them to say "Hey, guys, please don't do that, we were using that first". LV2 uses URI's to identify extensions and there is an expectation that the URI is based on a URL controlled by the extension's proponents. Namespacing, put simply. VST3. Cough. Choke. Do you know that the SDK Steinberg distributes for VST3 is larger than the entire Ardour codebase?
- spacechild1 6y ago
  > 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 need (https://github.com/steinbergmedia/vst3_pluginterfaces https://github.com/steinbergmedia/vst3_pluginterfaces). I don't think the actual VST3 plugin API is significantly larger than LV2. I have mixed feelings about VST3. I see some of the advantages, but some design decision are just awful. In fact, some things like multi-channel support is even worse than with VST2 (see https://github.com/steinbergmedia/vst3sdk/issues/28 https://github.com/steinbergmedia/vst3sdk/issues/28).
  - PaulDavisThe1st 6y ago
    Sadly, I'm no fan of COM either. It's an engineering design that while conceptually not unrelated to better similar systems of its time, just reeks of everything that was wrong with MS during the 1990s. I don't think that anyone that actually cares about cross-platform would ever choose COM-like stuff for anything. Or maybe I'm just no fan of "component object models" in general. But anyway, Robin Gareus has already implemented the bulk of VST3 support inside Ardour so we should that emerge sometime (7.0 or before).
    - spacechild1 6y ago
      > Sadly, I'm no fan of COM either. Me neither :-) A C API should still be the weapon of choice. > Robin Gareus has already implemented the bulk of VST3 Cool! I remember I had a short e-mail conversation with Robin about the VST3 SDK last year after he kindly helped me to get his lv2vst plugin to work in my host. Looks like he started to work on the VST3 implementation shortly after that :-)
      - prokoudine 6y ago
        Out of curiosity, what's your host's name? :)
        spacechild1 6y ago
        https://git.iem.at/pd/vstplugin https://git.iem.at/pd/vstplugin It's for Pure Data and Supercollider. GitHub mirror: https://github.com/spacechild1/vstplugin https://github.com/spacechild1/vstplugin
  - spacechild1 6y ago
    BTW, the actual VST3 plugin interface only consists of a couple of header files. I didn't have to compile a single .cpp file from the VST3 SDK. So the actual API is pretty light-weight, but it's quasi hidden inside this humongous SDK. It's both funny and sad.
- PaulDavisThe1st 6y ago
  Edit: larger than libardour if you exclude the cmake sources included within it. Larger than ardour if you include the cmake sources included.

PaulDavisThe1st 6y ago

What Cockos did with Reaper and their VST "extensions" is absolutely not part of Steinberg's conception of VST. Because of this, there's no namespacing: two organizations could "define" an extension that uses the same integer value for the audiomaster callback, and there's nothing to resolve that except for one of them to say "Hey, guys, please don't do that, we were using that first". LV2 uses URI's to identify extensions and there is an expectation that the URI is based on a URL controlled by the extension's proponents. Namespacing, put simply. VST3. Cough. Choke. Do you know that the SDK Steinberg distributes for VST3 is larger than the entire Ardour codebase?

spacechild1 6y ago
> 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 need (https://github.com/steinbergmedia/vst3_pluginterfaces https://github.com/steinbergmedia/vst3_pluginterfaces). I don't think the actual VST3 plugin API is significantly larger than LV2. I have mixed feelings about VST3. I see some of the advantages, but some design decision are just awful. In fact, some things like multi-channel support is even worse than with VST2 (see https://github.com/steinbergmedia/vst3sdk/issues/28 https://github.com/steinbergmedia/vst3sdk/issues/28).
- PaulDavisThe1st 6y ago
  Sadly, I'm no fan of COM either. It's an engineering design that while conceptually not unrelated to better similar systems of its time, just reeks of everything that was wrong with MS during the 1990s. I don't think that anyone that actually cares about cross-platform would ever choose COM-like stuff for anything. Or maybe I'm just no fan of "component object models" in general. But anyway, Robin Gareus has already implemented the bulk of VST3 support inside Ardour so we should that emerge sometime (7.0 or before).
  - spacechild1 6y ago
    > Sadly, I'm no fan of COM either. Me neither :-) A C API should still be the weapon of choice. > Robin Gareus has already implemented the bulk of VST3 Cool! I remember I had a short e-mail conversation with Robin about the VST3 SDK last year after he kindly helped me to get his lv2vst plugin to work in my host. Looks like he started to work on the VST3 implementation shortly after that :-)
    - prokoudine 6y ago
      Out of curiosity, what's your host's name? :)
      - spacechild1 6y ago
        https://git.iem.at/pd/vstplugin https://git.iem.at/pd/vstplugin It's for Pure Data and Supercollider. GitHub mirror: https://github.com/spacechild1/vstplugin https://github.com/spacechild1/vstplugin
- spacechild1 6y ago
  BTW, the actual VST3 plugin interface only consists of a couple of header files. I didn't have to compile a single .cpp file from the VST3 SDK. So the actual API is pretty light-weight, but it's quasi hidden inside this humongous SDK. It's both funny and sad.
PaulDavisThe1st 6y ago
Edit: larger than libardour if you exclude the cmake sources included within it. Larger than ardour if you include the cmake sources included.