Rust Audio

[rust-vst] Discussion: Crate Direction / Raph's Questions

Raph posted an excellent set of questions on issue #81:

I think these questions are important to discuss because they get at the fundamental goals, focus, and direction of the crate. I also figured this topic would be a nice way to stress-test this shiny new Discourse forum :slight_smile: .

I’m not really sure what the endgame of this post is (consensus?! wishful thinking…), but let’s discuss anyway!

And here are what I think the answers should be:

  1. Yes. Reviewers should not allow code with safety violations, and we should look into sanitizers etc.
  2. Yes. A great first step is runtime monitoring of allocations on the realtime thread.
  3. Minimal.
  4. Not a goal, this should be the goal of a wrapper (because different people are likely to approach this differently).
  5. Not a high priority. Things have to be reworked for progress.
  6. It would be great, and is important for people working at a low level with VST. I’ll note that with YesLogic’s OpenType work, they’re making this a high priority.
  7. Ultimately the scope can be both but we should get a working plugin first.
  8. Strong initial focus on x86_64 at first, but will accept patches for other platforms.
  9. No opinion. There’s lots of really interesting work being done on GUI (not just mine, see makepad), and it’s too early to standardize on one.
  10. Leaning no opinion, but I’m softer here. If there’s a really good lock-free queue available, I’m ok with it being provided.
  11. Definitely not, people need to be free to explore and experiment.
  12. I think it would be useful to build the higher levels with some abstraction over the plugin, and work in other formats.

Of course, other people might not agree, which is why it’s great to have a discussion!

My initial opinions/thoughts:

  1. I personally think thread-safety should be a core feature of the crate, but I can understand if some people feel like it’s imposing too much restriction on their design. I’ve been thinking about the possibility of a hierarchy of crates: Layer 1 could just hold all of the enums/structs we have lying around throughout the code (Category, Opcode, CanDo, etc.) – stuff that will be useful to literally any implementation of VST 2.4. Layer 2 could contain some sort of non-thread-safe FFI layer that you could theoretically use to make a VST relatively easily, but it doesn’t give you any safety guarantees (like our current crate without #65 or #85, but even simpler and without any implications of safety). Layer 3: from there, people could go experiment with their favorite thread-safety scheme (as rigorous as they’d like), and I think the rust-dsp group should also hash out at least one L3 and formally support it for the greater Rust ecosystem (including tutorials and such). Worst-case scenario, some people in the group don’t like the direction the official L3 is going, and they go off and develop their own L3. Whether or not we put the “other” L3 crates in the rust-dsp group can be left open for discussion.
    • You could probably combine L1 and L2 into a base crate, and just have two layers.
    • Anyway, if the layering thing isn’t well-received by the group and we end up only having one crate, I would say yes, thread-safety is important.
    • I’m not sure at the present moment what sorts of review/validation/testing steps we should have, but I feel like any supporting testing/tooling to this end should be *in-scope for the rust-dsp project (not necessarily immediately, but long-term).
  2. Yes. I think the crate should definitely follow “time waits for nothing”. What users do on top of the crate is up to them, but we shouldn’t make that decision (by doing allocations or whatever) for them.
    • Again I’m not sure what sorts of review/validation/testing steps we should have, but I feel like any supporting testing/tooling should be in-scope for the rust-dsp project (maybe not immediately, but long-term).
  3. I think the answer to question #1 partly covers my thoughts on this – I’d like to separate the crates into layers so we can have the best of both worlds, but if I had to only have one crate I’d say make it bare-minimum (but still thread-safe). Either way, I think we should consider supporting utility crates (or modules in the main crate) that help others work with rust-vst though (which would contain stuff like AtomicFloat and others).
  4. See #1 again :slight_smile: If we go the one crate route, I’d rather have this one be as simple as possible (yet still thread-safe and allocation/lock free), and let others build on top of it.
  5. IMO, not important at all, until some theoretical version 1.0. I’d rather do it correctly now than have to constantly deal with some issue years down the road just because of backwards compatibility. People can always target specific previous versions in their Cargo.toml to keep their tutorial code working, worst case.
  6. I’d like this crate to work with as many DAWs as possible, on all three major platforms (Windows, Mac, Linux).
  7. We should support hosts as well. This is actually where the layers thing from answer #1 comes in handy, because we could decide to split the plugins into client/host if we wanted to (I’m indifferent on whether or not we actually do this though).
  8. Are there a lot of DAWs for things other than x86(_64)? I’m mostly interested in x86_64, but it would be cool later if we ever make our own DAW for, say, RISC V. :slight_smile:
  9. I think rust-vst should have no opinion; it should be able to integrate with anything that implements Editor . I would much prefer to leave potential GUI implementations in separate crates, though. If I had to choose one, I would want to focus on a native editor (instead of, say, webasm or whatever), but I wouldn’t be annoyed if some other people worked on that too. Long-term, I want to see as many different GUI implementations as possible. :slight_smile: More choice is always good. Short-term, I want something that I can start to work with, like yesterday.
  10. Layers from #1 helps here – people could be free to implement whatever thread-safe thing they want. If we only have one crate, I have no opinion other than I want the most flexible thing possible.
  11. I have no opinion here. Same as answer #10 really.
  12. Short-term: I just want to make VST 2.4 plugins. I’d be fine if we just focused on that for now, even if we end up making it incompatible with other plugin formats. (Extremely) Long-term: It would be nice if we can carve out some common functionality between all the plugin formats and shove that stuff into separate crates (so that you can re-use the stuff), but I’d say rust-vst should only focus on VST 2.4. Those other plugin formats can be separate projects, with separate crates. Gotta be careful about issues with lowest-common-denominators and all that, but it would be nice to write a synth once and have it work in all the plugin formats too. Meh…

Neutral on supporting hosts, but I think they should be separate crates. It’s going to be rare that somebody wants to write a VST that also hosts VSTs (if such a thing is even possible).

Host and client are a bit intertwined – one example that comes to mind immediately is automate.

This might be a good usecase for my “layering” idea though, because then you could have “base”, “plugin”, and “host” crates. I’d have to look into it more though to see how separated they can really be.

  1. Absolutely. Safe wrappers like this are part of what makes Rust great. It can make sense to split out a lower-level, unsafe crate containing just the raw VST2 API, but I don’t think that more than one layer below rust-vst is needed.
    Safety validation is tricky, as it hinges on the host following the established guidelines for threading behavior. But we seem to have a reasonable understanding of those by now.
  2. What users do in their own code is their problem, but the wrapper code must not do any allocations (or locking synchronization) in processing functions.
  3. Yes. A minimal, safe, unopinionated wrapper with a few (somewhat opinionated) utilities for common situations.
  4. It should be reasonably approachable (and I think it is), but minimality and flexibility are more important.
  5. We should allow ourselves to break users’ code as long as there is a clear and manageable guideline for how to port old code.
  6. It could be great to have a document about this, outlining the precise assumptions that the crate makes about host behavior.
  7. Both. I think the current design, where the plugin and host see the exact same API, gives some nice possibilities, and we should strive to retain that. Such a design does not lend itself well to splitting up the crate into a plugin and a host crate, but I also don’t think this separation is particularly desirable.
  8. Definitely both 32 and 64 bit. I still see a lot of demand for 32-bit builds of my VSTs.
  9. I think it it fine for rust-vst to just expose the raw VST2 interface here, as it currently does. Window/input/graphics crates can then be designed separately to fit into the structure of rust-vst.
  10. It should not impose a particular mechanism, but should provide some ready-to-use options.
  11. I’d say DSP graphs are outside the scope of this crate.
  12. This crate should focus on VST2. Cross-API crates can be built on top.

This is an awesome discussion! I think we’re getting a good focus going forward.

I like the idea of making the rust-vst crate simple and easy to use, but minimal so that it just focuses on being a safe way to either host plugins with or to be hosted by. If we can make that minimal thing thread safe and performant (avoiding allocations on main audio thread), then that is awesome. I don’t think we should try to put much more into it than that, because I feel like people have a lot of differing opinions on higher-level niceties, and that seems to block PR’s from landing. I think we could definitely offer a “batteries included” solution for getting folks going quickly, but maybe keep that outside of the main repo so that we can cater to different opinions and also keep the main VST code solid.

I don’t know the best way to draw the line, but maybe some of you smarter folks can help figure that out.

1 Like