4 ms·

Clap: New MIT license audio plug-in format from Bitwig

77 points by brudgers 4y ago

CyMonk 4y ago
https://news.ycombinator.com/item?id=31759128 https://news.ycombinator.com/item?id=31759128 10 days ago|135 comments
atoav 4y ago
Everybody knows about standards and adding a new one, but I must say if I trust one company to get it right it is bitwig. The way they implemented modulations, MIDI Polyphonic Expresions etc within their own DAW shows that they really do care about creating good solutions with a fresh look — something that I would not trust AVID or Steinberg with at all.
speps 4y ago
I don't know a ton about this domain but isn't the name "CLAP" stupidly hard to search for compared to "VST"? It'll certainly confuse a few search engines for a while...
foxhill 4y ago
quite some time ago, i used to write audio plugins. i'd started by using WDL-OL[1], but quickly ended up re-writing most of the front-end code to use Direct2D/Cocoa + OpenGL, as i began to run into limitations with the rendering capabilities. in time, i ended up rewriting most of the framework in order to take advantage of VST3 and AAX's more.. separated APIs. Steinberg did some really good work with the design of VST3, and it's frustrating that it never really took off. it's the only plugin API that can actually guarantee sample-accuracy. the initial design required UI and processor separation. it turns out that latter point seems to unstick many developers. contrasted with AAX (which i'm also keen on), AAX allows for even more modular architectures (which you'd need to operate around, if you wanted to use their DSP hardware), however, AVID - perhaps learning from VST3's mistakes - made "singleton" architectures allowable straight away. a subsequent release of VST3 allowed for singleton architectures, given that so many people seemed to be put off with the (imo slightly) increased complexity, but it was too late. at least until recently, people are still writing VST2 plugins, and VST3 support across DAWs is not as extensive as VST2's. EDIT: ah! it looks like CLAP has delivered something i've been after in an audio API for some time: it appears to allow for dynamic parameters. i'm surprised it took this long! overall it looks well written too. i wonder if this will gain any traction in the DAW space. [1] - https://github.com/olilarkin/wdl-ol https://github.com/olilarkin/wdl-ol
- tialaramex 4y ago
  > EDIT: ah! it looks like CLAP has delivered something i've been after in an audio API for some time: it appears to allow for dynamic parameters. i'm surprised it took this long! What does this mean? I can imagine it being reasonable to have, for example, a wet/dry pot for a thing that's "not present" if you didn't enable the thing, since that pot is useless. Whether you want to reflect that as the pot magically "not existing" or just "disable" it or something so that user knows it isn't important is a small matter. I'm way more dubious about genuinely dynamic parameters. If I can't look at your plug-in and decide it has 24 parameters, but must instead reason that it could have any number of parameters and those might change (every sample? every bar? On reload? Once per week?) then automation becomes unmanageable. If you say, but some of the parameters are not automatable - too bad, somebody will want to automate those parameters too anyway and they will fight you to do it.
  - olivejun 4y ago
    I think they were referring to the audio API itself when mentioning wanting dynamic parameters to implement when writing plugins. I may be wrong though! Also, I just want to say in general, devs in music tech need a lot more love :( Fighting a dev over a design decision in a plugin is really commonplace online for some reason and its unfortunate being that most complaints can be easily solved with a solid foundation in sound and digital audio.
    - tialaramex 4y ago
      In this context by "fight you" I meant things like you find that even though you surface an automation API as expected, since they can't automate the things they want through your API they cause your GUI to run, inside a virtual environment in which the "pointer" is controlled by their software so as to click on gadgets at the appropriate time and then they whine that your plug-in (which is rendering a GUI) is too bloated and slow compared to the plug-ins that they're doing conventional automation for.
  - foxhill 4y ago
    > What does this mean? so the particular use-case was for a sampler. we had a bunch of different samples that had their own domain parameters, which needed to be automatable. hell, even multi-sample sample selection (the process of choosing which samples of a multisampled sample-set to use) was automatable. it was hell.. aha. that said, i envisenged a few other scenarios although they mostly revolve around variable IO (e.g. variable numbers of sidechained inputs, etc.) > I'm way more dubious about genuinely dynamic parameters. you're right to be. the approach i came up with was a conceptually a mess - although i guess it worked - the dynamic portions of automation could be mapped basically the same way that one routes audio in the daw. you have, say, 10 automatable gain parameters visible to the host, then in the plugin you'd route that to your chosen parameter. no joke, there was the question of making the parameter mapping itself automatable. i told them it was impossible and i would die on that hill, which is technically not a lie.

77 points by brudgers 4y ago

https://news.ycombinator.com/item?id=31759128 https://news.ycombinator.com/item?id=31759128 10 days ago|135 comments

Everybody knows about standards and adding a new one, but I must say if I trust one company to get it right it is bitwig. The way they implemented modulations, MIDI Polyphonic Expresions etc within their own DAW shows that they really do care about creating good solutions with a fresh look — something that I would not trust AVID or Steinberg with at all.

speps 4y ago

I don't know a ton about this domain but isn't the name "CLAP" stupidly hard to search for compared to "VST"? It'll certainly confuse a few search engines for a while...

foxhill 4y ago

quite some time ago, i used to write audio plugins. i'd started by using WDL-OL[1], but quickly ended up re-writing most of the front-end code to use Direct2D/Cocoa + OpenGL, as i began to run into limitations with the rendering capabilities. in time, i ended up rewriting most of the framework in order to take advantage of VST3 and AAX's more.. separated APIs. Steinberg did some really good work with the design of VST3, and it's frustrating that it never really took off. it's the only plugin API that can actually guarantee sample-accuracy. the initial design required UI and processor separation. it turns out that latter point seems to unstick many developers. contrasted with AAX (which i'm also keen on), AAX allows for even more modular architectures (which you'd need to operate around, if you wanted to use their DSP hardware), however, AVID - perhaps learning from VST3's mistakes - made "singleton" architectures allowable straight away. a subsequent release of VST3 allowed for singleton architectures, given that so many people seemed to be put off with the (imo slightly) increased complexity, but it was too late. at least until recently, people are still writing VST2 plugins, and VST3 support across DAWs is not as extensive as VST2's. EDIT: ah! it looks like CLAP has delivered something i've been after in an audio API for some time: it appears to allow for dynamic parameters. i'm surprised it took this long! overall it looks well written too. i wonder if this will gain any traction in the DAW space. [1] - https://github.com/olilarkin/wdl-ol https://github.com/olilarkin/wdl-ol

tialaramex 4y ago
> EDIT: ah! it looks like CLAP has delivered something i've been after in an audio API for some time: it appears to allow for dynamic parameters. i'm surprised it took this long! What does this mean? I can imagine it being reasonable to have, for example, a wet/dry pot for a thing that's "not present" if you didn't enable the thing, since that pot is useless. Whether you want to reflect that as the pot magically "not existing" or just "disable" it or something so that user knows it isn't important is a small matter. I'm way more dubious about genuinely dynamic parameters. If I can't look at your plug-in and decide it has 24 parameters, but must instead reason that it could have any number of parameters and those might change (every sample? every bar? On reload? Once per week?) then automation becomes unmanageable. If you say, but some of the parameters are not automatable - too bad, somebody will want to automate those parameters too anyway and they will fight you to do it.
- olivejun 4y ago
  I think they were referring to the audio API itself when mentioning wanting dynamic parameters to implement when writing plugins. I may be wrong though! Also, I just want to say in general, devs in music tech need a lot more love :( Fighting a dev over a design decision in a plugin is really commonplace online for some reason and its unfortunate being that most complaints can be easily solved with a solid foundation in sound and digital audio.
  - tialaramex 4y ago
    In this context by "fight you" I meant things like you find that even though you surface an automation API as expected, since they can't automate the things they want through your API they cause your GUI to run, inside a virtual environment in which the "pointer" is controlled by their software so as to click on gadgets at the appropriate time and then they whine that your plug-in (which is rendering a GUI) is too bloated and slow compared to the plug-ins that they're doing conventional automation for.
- foxhill 4y ago
  > What does this mean? so the particular use-case was for a sampler. we had a bunch of different samples that had their own domain parameters, which needed to be automatable. hell, even multi-sample sample selection (the process of choosing which samples of a multisampled sample-set to use) was automatable. it was hell.. aha. that said, i envisenged a few other scenarios although they mostly revolve around variable IO (e.g. variable numbers of sidechained inputs, etc.) > I'm way more dubious about genuinely dynamic parameters. you're right to be. the approach i came up with was a conceptually a mess - although i guess it worked - the dynamic portions of automation could be mapped basically the same way that one routes audio in the daw. you have, say, 10 automatable gain parameters visible to the host, then in the plugin you'd route that to your chosen parameter. no joke, there was the question of making the parameter mapping itself automatable. i told them it was impossible and i would die on that hill, which is technically not a lie.