5 ms·

clap is way better

by Polarity 11mo ago

clap is way better

codedokode 11mo ago
Clap doesn't allow describing plugin in a manifest (like VST3 and LV2 do). This allows to scan for plugins faster. Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events). This requires to write several converters when implementing a host. But, CLAP is much simpler and doesn't use COM-like system (VST3 resembles a Windows COM library with endless interfaces and GUIDs). Also, VST3 interfaces in SDK are described as C++ classes with virtual functions (example: [1]), and I wonder how do they achieve portability, if the layout for such classes (vtables) is not standardized and may differ across compilers. [1] https://github.com/steinbergmedia/vst3_pluginterfaces/blob/31d6eeba6daaa3e2a8bfbe3e7a90ca0b7fbfbc1c/vst/ivstaudioprocessor.h#L259 https://github.com/steinbergmedia/vst3_pluginterfaces/blob/3...
- Zoadian 11mo ago
  they are com classes. the vtable layout for them is specified.
  - debugnik 11mo ago
    Not really, VST3's COM-like API just uses virtual methods, they don't guarantee layout to the same degree actual COM does with compiler support. They simply rely on the platform ABI being standardized enough.
  - codedokode 11mo ago
    I don't think GCC has a special case for handling COM classes. However, I found that GCC uses "Itanium CXX ABI" on Linux which specifies vtable layout which accidentally might match the layout of COM classes. However, it is not guaranteered (for example, by C++ standards) that other compilers use the same layout.
    - duped 11mo ago
      The ABI is stable everywhere VST3s are used. It has to be or nothing would work.
      - codedokode 11mo ago
        Everything would work except for VST3, if written according to standards.
        duped 11mo ago
        The ABI isn't covered by C++ standards, it's target and architecture dependent. For the purposes of this discussion that ABI is stable for C++ vtables on the targets and architectures that VST3 supports. If a compiler and linker don't follow those ABIs then it would also be close to useless for compiling or linking against shared libraries. So in the wild, all useful compilers do target the same ABIs. gcc in mingw on windows is the odd duck, but most production software does not support it anyway.
        codedokode 11mo ago
        > If a compiler and linker don't follow those ABIs then it would also be close to useless for compiling or linking against shared libraries. I guess in C++ you are not supposed to link libraries produced by different compilers? Maybe you should use C-compatible interfaces in this case?
        duped 11mo ago
        You are, you can, and people do. Sure you should use C interfaces, that's what CLAP does, and it's easier to understand as a result. The C standard similarly does not specify an ABI.
- duped 11mo ago
  >Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events) Contrast to VST3 which doesn't support MIDI at all, unless you count cresting thousands of dummy parameters hardcoded to MIDI controller numbers "support."
  - codedokode 11mo ago
    VST3 uses proprietary events for things like note on/off and note expressions. As for MIDI controllers, the host is supposed to convert them to parameter changes. This makes sense if you want to map a controller to a plugin parameter in a DAW. However, if you want to write a "MIDI effect", which transforms incoming MIDI data for controllers, it would be difficult. Also it is interesting that VST3 has an event for note expression, and separate event for polyphonic pressure although it can be considered a note expression.
    - duped 11mo ago
      > As for MIDI controllers, the host is supposed to convert them to parameter changes And nearly everyone except Steinberg considers this to be a mistake. MIDI messages (CCs, pitch bend, and so on) are _not_ parameters.
      - codedokode 11mo ago
        As I understand it is better because it gives more freedom in routing parameter values. The parameter values might come not only from a MIDI controller knob directly, but from an automation curve, or from other plugin output, or from an automation track output. For example, you might combine 2 automation curves through a multiplication plugin and route the output to a plugin's parameter input. Or you could have an automation curve that produces a sine wave, and have a MIDI knob to modulate its amplitude, and send the result to an LPF "cutoff frequency" input, so that you can control amount of modulation with a knob. So VST3 (and CLAP) treat each parameter as an additional plugin input, which can be routed arbitrarily. If a plugin would instead have a single MIDI input and extract controller changes from a MIDI stream, then the scenario above would be more difficult to implement (you would need to convert an output of multiplication plugin into a sequence of MIDI controller changes and combine it with other MIDI events). Am I missing something here? Never developed a single plugin.
- wrl 11mo ago
  > Clap doesn't allow describing plugin in a manifest (like VST3 and LV2 do). This allows to scan for plugins faster. VST3 only recently gained the `moduleinfo.json` functionality and support is still materialising. Besides, hosts generally do a much better job about only scanning new plugins or ones that have changed, and hosts like Bitwig even do the scanning in the background. The manifest approach is cool, but in the end, plugin DLLs just shouldn't be doing any heavy lifting until they actually need to create an instance anyway. > Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events). This requires to write several converters when implementing a host. I've not done the host-side work, but the plugin-side work isn't too difficult. It's the same data, just represented differently. Disclaimer: I don't support MIDI2 yet, but I support the other 3. On the other side, VST3 has some very strange design decisions that have led me to a lot of frustration. Having separate parameter queues for sample-accurate automation requires plugins to treat their parameters in a very specific way (basically, you need audio-rate buffers for your parameter values that are as long as the maximum host block) in order to be written efficiently. Otherwise plugins basically have to "flatten" those queues into a single queue and handle them like MIDI events, or alternately just not handle intra-block parameter values at all. JUCE still doesn't handle these events at all, which leads to situations where a VST2 build of a JUCE plugin will actually handle automation better than the VST3 build (assuming the host is splitting blocks for better automation resolution, which all modern hosts do). duped's comment about needing to create "dummy" parameters which get mapped to MIDI CCs is spot-on as well. JUCE does this. 2048 additional parameters (128 controllers * 16 channels) just to receive CCs. At least JUCE handles those parameters sample-accurately! There's other issues too but I've lost track. At one point I sent a PR to Steinberg fixing a bug where their VST3 validator (!!!) was performing invalid (according to their own documentation) state transitions on plugins under test. It took me weeks to get the VST3 implementation in my plugin framework to a shippable state, and I still find more API and host bugs than I ever hit in VST2. VST3 is an absolute sprawl of API "design" and there are footguns in more places than there should be. On the contrary, CLAP support took me around 2 days, 3 if we're being pedantic. The CLAP API isn't without its share of warts, but it's succinct and well-documented. There's a few little warts (the UI extension in particular should be more clear about when and how a plugin is supposed to actually open a window) but these are surmountable, and anecdotally I have only had to report one (maybe two) host bugs so far. Again, disclaimer: I was involved in the early CLAP design efforts (largely the parameter extension) and am therefore biased, but if CLAP sucked I wouldn't shy away from saying it.
pjbk 11mo ago
You would have thought they learned from their mistakes implementing VST2, but they doubled down going even further basing VST3 on the Windows Component Object Model. I guess it was a decision to avoid reinventing the wheel, but you can quickly realize it is a very bad model for real time audio plugins and audio host support. The API just exploded in complexity, and testing was a nightmare. In contrast you can tell the U-He developers have all the experience from the trenches.
- p0nce 11mo ago
  > it is a very bad model for real time audio plugins and audio host support COM is just 3 predefined calls in the virtual table. CLAP gives you a bunch of pointers to functions, which is similar.
  - jsmith45 11mo ago
    > COM is just 3 predefined calls in the virtual table. COM can be as simple as that implementation side, at least if your platforms vtable ABI matches COM's perfectly, but it also allows far more complicated implementations where every implemented interface queried will allocate a new distinct object, etc. I.E. even if you know for sure that the object is implemented in c++, and your platforms' vtable ABI matches COM's perfectly, and you know exactly what interfaces the object you have implements, you cannot legally use dynamic_cast, as there is no requirement that one class inherits from both interfaces. The conceptual "COM object" could instead be implemented as one class per interface, each likely containing a pointer to some shared data class. This is also why you need to do the ref counting with respect to each distinct interface, since while it is legal from an implementation side to just share one ref count for it all, that is in no way required.
    - deleted 11mo ago
      [deleted]
    - debugnik 11mo ago
      Note that VST3 doesn't implement the COM vtable layout, their COM-like FUnknown really is just 3 virtual methods and a bunch of GUIDs. They rely on the platform's C++ ABI not breaking. You're right that QueryInterface can return a different object, but that doesn't make it significantly more complicated, assuming you're not managing the ref-counts manually.
deleted 11mo ago
[deleted]

clap is way better

Clap doesn't allow describing plugin in a manifest (like VST3 and LV2 do). This allows to scan for plugins faster. Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events). This requires to write several converters when implementing a host. But, CLAP is much simpler and doesn't use COM-like system (VST3 resembles a Windows COM library with endless interfaces and GUIDs). Also, VST3 interfaces in SDK are described as C++ classes with virtual functions (example: [1]), and I wonder how do they achieve portability, if the layout for such classes (vtables) is not standardized and may differ across compilers. [1] https://github.com/steinbergmedia/vst3_pluginterfaces/blob/31d6eeba6daaa3e2a8bfbe3e7a90ca0b7fbfbc1c/vst/ivstaudioprocessor.h#L259 https://github.com/steinbergmedia/vst3_pluginterfaces/blob/3...

Zoadian 11mo ago
they are com classes. the vtable layout for them is specified.
- debugnik 11mo ago
  Not really, VST3's COM-like API just uses virtual methods, they don't guarantee layout to the same degree actual COM does with compiler support. They simply rely on the platform ABI being standardized enough.
- codedokode 11mo ago
  I don't think GCC has a special case for handling COM classes. However, I found that GCC uses "Itanium CXX ABI" on Linux which specifies vtable layout which accidentally might match the layout of COM classes. However, it is not guaranteered (for example, by C++ standards) that other compilers use the same layout.
  - duped 11mo ago
    The ABI is stable everywhere VST3s are used. It has to be or nothing would work.
    - codedokode 11mo ago
      Everything would work except for VST3, if written according to standards.
      - duped 11mo ago
        The ABI isn't covered by C++ standards, it's target and architecture dependent. For the purposes of this discussion that ABI is stable for C++ vtables on the targets and architectures that VST3 supports. If a compiler and linker don't follow those ABIs then it would also be close to useless for compiling or linking against shared libraries. So in the wild, all useful compilers do target the same ABIs. gcc in mingw on windows is the odd duck, but most production software does not support it anyway.
        codedokode 11mo ago
        > If a compiler and linker don't follow those ABIs then it would also be close to useless for compiling or linking against shared libraries. I guess in C++ you are not supposed to link libraries produced by different compilers? Maybe you should use C-compatible interfaces in this case?
        duped 11mo ago
        You are, you can, and people do. Sure you should use C interfaces, that's what CLAP does, and it's easier to understand as a result. The C standard similarly does not specify an ABI.
duped 11mo ago
>Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events) Contrast to VST3 which doesn't support MIDI at all, unless you count cresting thousands of dummy parameters hardcoded to MIDI controller numbers "support."
- codedokode 11mo ago
  VST3 uses proprietary events for things like note on/off and note expressions. As for MIDI controllers, the host is supposed to convert them to parameter changes. This makes sense if you want to map a controller to a plugin parameter in a DAW. However, if you want to write a "MIDI effect", which transforms incoming MIDI data for controllers, it would be difficult. Also it is interesting that VST3 has an event for note expression, and separate event for polyphonic pressure although it can be considered a note expression.
  - duped 11mo ago
    > As for MIDI controllers, the host is supposed to convert them to parameter changes And nearly everyone except Steinberg considers this to be a mistake. MIDI messages (CCs, pitch bend, and so on) are _not_ parameters.
    - codedokode 11mo ago
      As I understand it is better because it gives more freedom in routing parameter values. The parameter values might come not only from a MIDI controller knob directly, but from an automation curve, or from other plugin output, or from an automation track output. For example, you might combine 2 automation curves through a multiplication plugin and route the output to a plugin's parameter input. Or you could have an automation curve that produces a sine wave, and have a MIDI knob to modulate its amplitude, and send the result to an LPF "cutoff frequency" input, so that you can control amount of modulation with a knob. So VST3 (and CLAP) treat each parameter as an additional plugin input, which can be routed arbitrarily. If a plugin would instead have a single MIDI input and extract controller changes from a MIDI stream, then the scenario above would be more difficult to implement (you would need to convert an output of multiplication plugin into a sequence of MIDI controller changes and combine it with other MIDI events). Am I missing something here? Never developed a single plugin.
wrl 11mo ago
> Clap doesn't allow describing plugin in a manifest (like VST3 and LV2 do). This allows to scan for plugins faster. VST3 only recently gained the `moduleinfo.json` functionality and support is still materialising. Besides, hosts generally do a much better job about only scanning new plugins or ones that have changed, and hosts like Bitwig even do the scanning in the background. The manifest approach is cool, but in the end, plugin DLLs just shouldn't be doing any heavy lifting until they actually need to create an instance anyway. > Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events). This requires to write several converters when implementing a host. I've not done the host-side work, but the plugin-side work isn't too difficult. It's the same data, just represented differently. Disclaimer: I don't support MIDI2 yet, but I support the other 3. On the other side, VST3 has some very strange design decisions that have led me to a lot of frustration. Having separate parameter queues for sample-accurate automation requires plugins to treat their parameters in a very specific way (basically, you need audio-rate buffers for your parameter values that are as long as the maximum host block) in order to be written efficiently. Otherwise plugins basically have to "flatten" those queues into a single queue and handle them like MIDI events, or alternately just not handle intra-block parameter values at all. JUCE still doesn't handle these events at all, which leads to situations where a VST2 build of a JUCE plugin will actually handle automation better than the VST3 build (assuming the host is splitting blocks for better automation resolution, which all modern hosts do). duped's comment about needing to create "dummy" parameters which get mapped to MIDI CCs is spot-on as well. JUCE does this. 2048 additional parameters (128 controllers * 16 channels) just to receive CCs. At least JUCE handles those parameters sample-accurately! There's other issues too but I've lost track. At one point I sent a PR to Steinberg fixing a bug where their VST3 validator (!!!) was performing invalid (according to their own documentation) state transitions on plugins under test. It took me weeks to get the VST3 implementation in my plugin framework to a shippable state, and I still find more API and host bugs than I ever hit in VST2. VST3 is an absolute sprawl of API "design" and there are footguns in more places than there should be. On the contrary, CLAP support took me around 2 days, 3 if we're being pedantic. The CLAP API isn't without its share of warts, but it's succinct and well-documented. There's a few little warts (the UI extension in particular should be more clear about when and how a plugin is supposed to actually open a window) but these are surmountable, and anecdotally I have only had to report one (maybe two) host bugs so far. Again, disclaimer: I was involved in the early CLAP design efforts (largely the parameter extension) and am therefore biased, but if CLAP sucked I wouldn't shy away from saying it.

pjbk 11mo ago

You would have thought they learned from their mistakes implementing VST2, but they doubled down going even further basing VST3 on the Windows Component Object Model. I guess it was a decision to avoid reinventing the wheel, but you can quickly realize it is a very bad model for real time audio plugins and audio host support. The API just exploded in complexity, and testing was a nightmare. In contrast you can tell the U-He developers have all the experience from the trenches.

p0nce 11mo ago
> it is a very bad model for real time audio plugins and audio host support COM is just 3 predefined calls in the virtual table. CLAP gives you a bunch of pointers to functions, which is similar.
- jsmith45 11mo ago
  > COM is just 3 predefined calls in the virtual table. COM can be as simple as that implementation side, at least if your platforms vtable ABI matches COM's perfectly, but it also allows far more complicated implementations where every implemented interface queried will allocate a new distinct object, etc. I.E. even if you know for sure that the object is implemented in c++, and your platforms' vtable ABI matches COM's perfectly, and you know exactly what interfaces the object you have implements, you cannot legally use dynamic_cast, as there is no requirement that one class inherits from both interfaces. The conceptual "COM object" could instead be implemented as one class per interface, each likely containing a pointer to some shared data class. This is also why you need to do the ref counting with respect to each distinct interface, since while it is legal from an implementation side to just share one ref count for it all, that is in no way required.
  - deleted 11mo ago
    [deleted]
  - debugnik 11mo ago
    Note that VST3 doesn't implement the COM vtable layout, their COM-like FUnknown really is just 3 virtual methods and a bunch of GUIDs. They rely on the platform's C++ ABI not breaking. You're right that QueryInterface can return a different object, but that doesn't make it significantly more complicated, assuming you're not managing the ref-counts manually.

deleted 11mo ago

[deleted]