4 ms·

There should just be a standard for a software module, like VST for plug-in instruments. Then they could re-used across platforms, and a DAW like Ableton could

by dmicah 5y ago

There should just be a standard for a software module, like VST for plug-in instruments. Then they could re-used across platforms, and a DAW like Ableton could theoretically host them directly without needing an intermediary VST host app like Rack.

squeaky-clean 5y ago
I believe the new CLAP plugin format U-He and Bitwig have recently released is an attempt at this and a few other benefits plugins have been lacking for a while.
- PaulDavisThe1st 5y ago
  CLAP (like every other audio/MIDI plugin API) does not cover single-sample processing, which one of the core design ideas in Rack's module API. And as an aside, CLAP has almost nothing in it that LV2 didn't already offer, and nothing that could not have been added to LV2 using the extension mechanism, but a rather severe case of NIH pushed things in the direction that they eventually went. It's quite unfortunate.
PaulDavisThe1st 5y ago
This is a misunderstanding of the difference between a DAW and a host like Rack. Rack performs single-sample processing. DAWs (all of them) use block-structured processing. For a DAW to host modules that are designed for single-sample processing would always require an intermediary. It might as well be Rack.
- dmicah 5y ago
  I know that each cable in VCV Rack imposes a 1-sample delay. However isn't the audio still transmitted to the audio interface in blocks? It's not clear why a DAW would need an intermediary in this case, other than something analogous to the VCV Rack 2 Pro VST instrument host. The reason not use Rack is so that it could be an open standard with multiple host implementations.
  - PaulDavisThe1st 5y ago
    > It's not clear why a DAW would need an intermediary in this case, other than something analogous to the VCV Rack 2 Pro VST instrument host. Because the modules are written to do single sample processing, which creates some design imperatives that are quite different from those used by regular audio plugin APIs where blocks of samples are passed around. "But, " you may say, " isn't single sample processing just passing around blocks of samples with a size == 1?" Well, sure, technically that's true, but you don't write code the same way if you know that the size is always 1. Ergo, you're going to need something to execute the modules in a single-sample style, not block structured. That intermediate will be functionally identical to Rack. Rack's API is completely open source, and anybody else could reimplement it. It would be horrible as a general audio plugin API, but it's pretty good for "rack modules".

by dmicah 5y ago

squeaky-clean 5y ago

I believe the new CLAP plugin format U-He and Bitwig have recently released is an attempt at this and a few other benefits plugins have been lacking for a while.

PaulDavisThe1st 5y ago
CLAP (like every other audio/MIDI plugin API) does not cover single-sample processing, which one of the core design ideas in Rack's module API. And as an aside, CLAP has almost nothing in it that LV2 didn't already offer, and nothing that could not have been added to LV2 using the extension mechanism, but a rather severe case of NIH pushed things in the direction that they eventually went. It's quite unfortunate.

PaulDavisThe1st 5y ago

This is a misunderstanding of the difference between a DAW and a host like Rack. Rack performs single-sample processing. DAWs (all of them) use block-structured processing. For a DAW to host modules that are designed for single-sample processing would always require an intermediary. It might as well be Rack.

dmicah 5y ago
I know that each cable in VCV Rack imposes a 1-sample delay. However isn't the audio still transmitted to the audio interface in blocks? It's not clear why a DAW would need an intermediary in this case, other than something analogous to the VCV Rack 2 Pro VST instrument host. The reason not use Rack is so that it could be an open standard with multiple host implementations.
- PaulDavisThe1st 5y ago
  > It's not clear why a DAW would need an intermediary in this case, other than something analogous to the VCV Rack 2 Pro VST instrument host. Because the modules are written to do single sample processing, which creates some design imperatives that are quite different from those used by regular audio plugin APIs where blocks of samples are passed around. "But, " you may say, " isn't single sample processing just passing around blocks of samples with a size == 1?" Well, sure, technically that's true, but you don't write code the same way if you know that the size is always 1. Ergo, you're going to need something to execute the modules in a single-sample style, not block structured. That intermediate will be functionally identical to Rack. Rack's API is completely open source, and anybody else could reimplement it. It would be horrible as a general audio plugin API, but it's pretty good for "rack modules".