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.
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.
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".