Okay, gathered together some thoughts finally, now that I’m home from work.
- I’m excited about the idea of an API-independent plugin suite, sounds like an awesome idea to me. However, I’d still like to be able to target specific plugin formats alone if I chose to do so.
- VST2 isn’t the only one I feel this way about; I’d like standalone VST3 and LV2 crates as well.
- I’m totally game to split the current VST2 crate into
vst-sys; that sounds useful to me regardless of if we have an API-independent suite or not.
- I’m still game to try to support the GUI story of any plugin crates we decide to support regardless; I think it’s important to support GUI features if the plugin format allows for it.
- If we decide to straight up delete the VST-specific crate, let me know beforehand so I can fork it
- I basically have no idea what I’m talking about when it comes to plugin formats other than VST2.
- I haven’t really worked with JUCE, haven’t looked at GMPI yet, and haven’t played around with any other multi-plugin-supporting suite ideas at all.
- I haven’t even “shipped” a plugin, nor even made a non-trivial VST yet, so some people (@wrl for sure) probably have a lot more knowledge on the topic of full-scale plugins than I do regardless.
My main concern:
Ok, I admit I might just be Afraid Of Change™ on this topic, but my gut reaction is that it’s going to be hard to support 4+ different plugins at the same while still being able to pay attention to plugin-specific details without either:
- forcing the user to write some per-plugin-format logic (eww), or
- degrading to some form of “lowest common denominator” API specification to handle all of the different formats.
Like I said earlier, I basically have no idea what I’m talking about when it comes to other plugin formats, but I imagine the differences are not too easy among the different plugin formats, like:
- differences in how the threading/concurrency works
- differences in how the GUIs work
- differences in how parameters work
- differences in how events work (MIDI, etc)
- differences in how channel setup works
- maybe even differences in how
process()equivalent functions work (?)
- 32 bit vs. 64 bit for parameters,
process(), events, and arguments to functions
I wasn’t able to find any actual numbers regarding plugin format market share, but I’m going to take a guess and say that VST2 is well in the lead at the current moment. Just from a pragmatic, “I just want to make a plugin right now” standpoint (and from the “I want to support the maximum number of people with the least amount of effort” standpoint), I’m going to argue that supporting VST2 as a standalone crate is still worth it, at least for now.
- If I find a bug in a VST2 plugin, it will be easier to identify it in a standalone crate vs. figuring out if it’s just the VST2 module of an API-independent crate, or if it’s a bug in the API wrapper portion, etc. And if it is in the API wrapper portion, how said bug would affect all of the other plugin types, how to fix them all, etc.
- If I want to experiment with my own concurrency model, I feel like it’s going to be difficult to work with 4+ plugin formats rather than just one. If I’m targeting just VST2, I can constrain my problem to just that domain and figure out a solution.
- Same thing as the previous bullet point, but for parameters and
- I’m going to guess that the API-independent crate will introduce a tiny bit of processing overhead, which I’d like to have the option of avoiding if I wanted to. (This isn’t a major concern, but options are always good.)
Basically, I guess what I’m saying is I’d like to maintain the option of trading off: 1) supporting all of the various plugin formats at the same time, vs. 2) supporting one plugin format with the ability to focus on details of that format. And, of the various different formats, VST2 is (unfortunately) de-facto the most “effort-effective” one to support if I wanted to make that tradeoff. If we do decide as the Rust DSP group to drop support for the higher-level VST2 crate, I’ll probably just fork it and maintain it myself in case I want to make that tradeoff in the future.
(I’d actually like to have this option for ALL of the different plugin formats, but realistically the only ones that affect me are VST2, VST3, and LV2.)
All that having been said, separating the crate into
vst-sys is something I can get behind regardless, so I’m on board to help work on that if needed.
Enough pessimism, here’s support for the idea:
Okay, putting the pragmatic side of things aside and speaking idealistically though, I agree with the sentiment of “screw Steinberg, VST2 isn’t even that great anyway, let’s garner support for the other plugin types and break the monopoly” – the audio community desperately needs more choices for plugin formats, and I personally don’t want to work with C++, so I think this is an awesome initiative.
I’m all on-board for the idea (minus the “throwing away support for targeting a single plugin” part).
- How do we decide which plugin formats to target? (I’m going to make another post for this)
- What happens if we decide we want to target a new one that we didn’t initially want to support? (IE is it easy to abstract it far enough that adding new plugin formats is easy?)
- For the set of plugin formats that we decide to support, I’d still like to have separate crates (not just modules inside the format-independent crate) of the
- We definitely need to figure out the “project management” aspect of this group pretty soon to tackle something of this size.
One specific response on this topic:
We lose a focused effort towards Rust support of the largest plugin format by market share. It sucks that Steinberg is grossly mismanaging the standard, but it is what it is. To be blunt myself, we don’t really move too quickly with one plugin format, let alone 4+ at the same time.