Intent to deprecate and archive vst-rs
wrl opened this issue · 17 comments
It is my opinion that this project is EOL and should be deprecated and archived.
My reasoning is the following:
-
VST2 as a format has been EOL for years. As of October 2018, it is no longer possible to acquire a license from Steinberg for distributing commercial products based on VST2.
-
vst-rs's legal status w.r.t. the VST2 SDK has always been a grey area. -
Because the abstractions in
vst-rsare not easily portable to other plugin formats, developers who program againstvst-rswill have to rewrite significant portions of their codebase in order to move away fromvst-rstoward other crates/APIs.Furthermore, the abstractions in
vst-rsare tightly coupled to the underlying VST2 programming model and are unsuitable as a basis for a more comprehensive multi-format plugin abstraction layer. -
There is little to no ongoing work on the
vst-rscrate. -
Developers continue to discover
vst-rsand start projects with it, despite the above points.
I am opening this issue to solicit discussion and feedback on the next steps for this crate. At the very least, I think we should change the README to have a big obnoxious deprecation notice discouraging its use for new projects. As mentioned, my goal here is to deprecate and archive the project here on Github, leaving it read-only.
I'm going to give two months for discussion and revisit the issue in mid-January 2023, with an intent to archive the repo at the beginning of February 2023.
I see no laternatives for my case. So it it not just a random discovery.
I want to have a host for my favorite plugin to have a synth sound in my project. The plugin is commetcial (Pianoteq) and has lv2 and vst interfaces. lv2 also does not seem to be in favor these days. Besides I would still want to keep cross-platform option open.
Not a big prioblem deprecating the project for me as the sources will still be available.
In general, one should never deprecate software wihout offering alternatives. This part is missing.
Legal-wise, do hosts also need a license?
I see no laternatives for my case. So it it not just a random discovery. I want to have a host for my favorite plugin to have a synth sound in my project. The plugin is commetcial (Pianoteq) and has lv2 and vst interfaces. lv2 also does not seem to be in favor these days.
There is an active development community surrounding LV2. At the very least, it is substantially more in favour than VST2 is, and there already exist LV2 crates for Rust as well.
Besides I would still want to keep cross-platform option open.
LV2 plugins also run on Windows and Mac – it is not a Linux-only format.
Not a big prioblem deprecating the project for me as the sources will still be available. In general, one should never deprecate software wihout offering alternatives.
The deprecation notice will list the alternatives, which are nih-plug for plugin development and vst2-sys if you absolutely must use the VST2 API/ABI. Naturally, you will be able to continue using vst-rs if it is deprecated, but it will not receive any further updates.
Legal-wise, do hosts also need a license?
Yes, hosts also need a license, and, as mentioned, it is no longer possible to get one.
A big +1 for adding a deprecation notice to the README and directing readers to nih-plug. I just took a fresh look, and from what I could see, it's even easier to use than this crate. There's less manual work to handle events, and the parameter handling is much more declarative and streamlined.
I don't think it makes much sense to list vst2-sys as an alternative, though. All the same arguments about VST2 being obsolete apply in equal measure to that crate.
We should also officially deprecate the whole crate and post a new minor version (that would be 0.3.1) to crates.io such that all users get a warning when they compile a project that depends on this crate.
I am not sure I see the rationale for making the repository read-only, though. If someone who is actually using it for a good reason really wants to contribute improvements to the code, they should be able to do so.
This of course assumes that someone is actively maintaining it, at least to the point of reacting to pull requests. If nobody is willing to do that (and get free hands to do it - let's do away with the strict review requirements, which are way overkill for a project of this scale), then it could make sense to archive to send a clear signal that it is unmaintained. But before doing that, we should issue a call for maintainers to see if anyone might be willing to commit to that minimum level of maintenance.
It's been a lot of fun putting together the safe workarounds for the broken VST2 API (actually, I recently gave a talk about that). Even then, and Steinberg's behavior aside, I am happy there is now a proper solution which makes that workaround obsolete.
A big +1 for adding a deprecation notice to the README and directing readers to nih-plug. I just took a fresh look, and from what I could see, it's even easier to use than this crate. There's less manual work to handle events, and the parameter handling is much more declarative and streamlined.
I don't think it makes much sense to list vst2-sys as an alternative, though. All the same arguments about VST2 being obsolete apply in equal measure to that crate.
vst2-sys is only an alternative in the case where VST2 compatibility is a requirement. Otherwise, nih-plug is far an away the best option.
We should also officially deprecate the whole crate and post a new minor version (that would be 0.3.1) to crates.io such that all users get a warning when they compile a project that depends on this crate.
Agreed.
I am not sure I see the rationale for making the repository read-only, though. If someone who is actually using it for a good reason really wants to contribute improvements to the code, they should be able to do so.
My understanding is that archiving a repository puts it into a read-only state. This is what I'm advocating for.
This of course assumes that someone is actively maintaining it, at least to the point of reacting to pull requests. If nobody is willing to do that (and get free hands to do it - let's do away with the strict review requirements, which are way overkill for a project of this scale), then it could make sense to archive to send a clear signal that it is unmaintained. But before doing that, we should issue a call for maintainers to see if anyone might be willing to commit to that minimum level of maintenance.
The ship has sailed on VST2 as an API. My intent here is not to push for this crate to be maintained again so we can kick this can down the road another 6-12 months and then revisit the issue. The format is dead and this crate is too tightly bound to the VST2 API and its limitations to be useful for non-VST2 plugin development.
All of the other plugin development work in the Rust audio space is greenfield development. nih-plug eschews VST2 entirely. baseplug (my own prototypal framework) originally used vst-rs only for the low-level ABI defines until hitting UB when converting unhandled opcodes, so I switched to vst2-sys. None of the Rust work for other formats (LV2, CLAP) builds on vst-rs.
@wrl I looked at nih-plug, but could not find examples for host implementations, same for other LV2 projects I found. It seems that implementing DSP hosts is not what most (if not all) of the projects are interested in. My intention was to get midi->sound conversion with as little fuss as possible (while using Rust and Pianoteq) since it is not the actual problem I am trying to solve and I have never worked with audio plugins before.
I looked at Meadowlark DAW, it does have to be a host, but it will have only CLAP support suggesting that Carla could be used as adapter for all other APIs. So maybe that will be an option someday. None of that is implemented yet, though. I think I will have to stick with my current approach meanwhile.
@wrl I looked at nih-plug, but could not find examples for host implementations, same for other LV2 projects I found. It seems that implementing DSP hosts is not what most (if not all) of the projects are interested in.
Comprehensive cross-plugin format host implementations are vanishingly rare. I think JUCE is the only project that even attempts to provide it. All the other plugin frameworks I'm aware of do not.
My intention was to get midi->sound conversion with as little fuss as possible (while using Rust and Pianoteq) since it is not the actual problem I am trying to solve and I have never worked with audio plugins before. I looked at Meadowlark DAW, it does have to be a host, but it will have only CLAP support suggesting that Carla could be used as adapter for all other APIs. So maybe that will be an option someday. None of that is implemented yet, though. I think I will have to stick with my current approach meanwhile.
Personally, vst-rs's hosting code is one of the biggest problems I have with it. Having written multiple VST2 host implementations myself, it is considerably simpler to just do it on top of the vst2-sys ABI. Does it require unsafe? Yes, but the fact that vst-rs even attempts to present a safe API for hosting is a huge lie.
Fundamentally, what you want this crate to do (provide an easy way to host VST2 plugins so that you don't have to think about the low-level ABI details) is not actually what it's doing. The API it provides is too bound to the underlying VST2 API and as such it would need backwards compatibility broken in order to make it work for non-VST2 plugin formats.
@wrl I am not looking for comprehensive or cross-API hosts (having that is a plus, of course). The problem is that none of the Rust projects that I have found seem to be interested in implementing hosts at all - only plugin-side (let alone, say https://github.com/MeadowlarkDAW/dropseed). E.g. nih-plug has "plug" in the name :)
I will look at vst2-sys - it seems that I cannot avoid unerstanding the APIs better anyway...
The problem is that none of the Rust projects that I have found seem to be interested in implementing hosts at all - only plugin-side
All of the existing raw API binding crates (vst2-sys, vst3-sys, clap-sys, auv2-sys, lv2-sys) are perfectly suitable for the purpose of plugin hosting; they just don't attempt to provide a safe abstraction over it.
Building that kind of safe abstraction would be a fairly monumental task, and it would also involve making a lot of arbitrary decisions, many of which are best left in the hands of a particular host application. I could still absolutely see the utility in a library providing that kind of abstraction, at the cost of some flexibility and performance, for applications with less demanding requirements; but since such a library doesn't currently exist in Rust, the best current solution is probably to get to know one or more of the plugin APIs directly and implement hosting functionality yourself.
Sure, this is more difficult than using vst-rs directly, but that doesn't make using vst-rs a good idea, for all of the reasons outlined in @wrl's initial post. There is no clear way to legally release a plugin or host developed using vst-rs, whether commercially or as free or open-source software, due to the licensing situation; there are currently various soundness issues with its abstractions; and there is little or no ongoing work towards improving this situation, largely due to the aforementioned legal issues. For these reasons, I don't think it's beneficial for anyone to build software on top of it, even in the absence of similarly easy-to-use libraries for other plugin APIs.
Adding a deprecation notice to the README and archiving the repository will send a clear message to those who stumble across this library that it is not a wise choice to depend on it. Something to this effect is definitely necessary, since new people continue to discover vst-rs and make the decision to build projects on top of it.
I use vst-rs regularly for coding little utility VSTs that I only use myself, and for that I would really like to keep using this crate!
(Not all hosts support VST3, and none of my VSTs need to be VST3. Sometimes I even use old 32-bit hosts that only support VST2.)
While I agree that it makes sense to amend the Readme to add a notice about the issues with licensing and API safety and point to those alternative crates, I don't think the repo should be archived / read-only, it should still be open to contributions.
I would be willing to maintain it / do PR reviews etc.
I would argue that for the sake of the users who do rely on this project few as they may be, that it would be better to start by marking the repo in a vary obvious way that it is deprecated and another solution should be preferred. If we must archive it I would prefer that it be at a date far enough in the future that any current users can migrate or fork if they so choose. 6 Months? And that date should be clearly posted in the README as well. After some transitional period that has been announced publicly I see no issue with archiving the project.
While I agree that it makes sense to amend the Readme to add a notice about the issues with licensing and API safety and point to those alternative crates, I don't think the repo should be archived / read-only, it should still be open to contributions. I would be willing to maintain it / do PR reviews etc.
My intent is not to solicit maintainership, as maintainership does not solve the soundness issues in the API or the issues with legality and licensing. Also, what's the point in warning about API safety for a crate that purports to be safe in the first place? There are API design issues that would need to be resolved, which would break compatibility, so people relying on the library would need to change their code anyway.
I would argue that for the sake of the users who do rely on this project few as they may be, that it would be better to start by marking the repo in a vary obvious way that it is deprecated and another solution should be preferred. If we must archive it I would prefer that it be at a date far enough in the future that any current users can migrate or fork if they so choose. 6 Months? And that date should be clearly posted in the README as well. After some transitional period that has been announced publicly I see no issue with archiving the project.
I'm not opposed to this, but just as a note of the timeframe – the most recent commit or merge on this repo was February 2022, which means that my proposed cutoff would be 1 year of inaction. And, to reiterate, it has been impossible to get a license for VST2 since October 2018, which is more than 4 years ago. Is an additional several months really going to make a difference? To me, it seems like we're just postponing the inevitable. People will continue to be able to use it when it is archived and deprecated, but its status will no longer be in limbo.
Meanwhile, developers new to the space continue to discover this crate, develop against it, join the Discord, ask why something or other doesn't work, and then are informed that they effectively have to rewrite their project against a different crate.
I will restate: this is an unmaintained, unsound crate that implements a vendor-deprecated API, and the fact that people continue to rely on it is the problem I am proposing we solve by deprecating and archiving it.
@wrl I’m aware of the issues and the long since deprecated status of vst2. I’m all for pushing towards better options for newcomers, I just also don’t want to abandon the long time users of this project without at least a decent amount of notice. Doesn’t have to be 6 months could be 1 or 2 for all I care, the point being that it is clear what the plan is and that there is some time built into the plan for the word to get out and for people to migrate.
@zyvitski Archiving the project will not prevent users from adding the crate as a Cargo dependency or cloning or forking the repo, so it shouldn't cause any difficulties for existing users of the crate.
In general it sounds like this is happening one way or the other. My question would be, when should it happen?
vst2-sysis only an alternative in the case where VST2 compatibility is a requirement. Otherwise,nih-plugis far an away the best option.
I do agree. What I mean is that for the specific use case of making VST2 plugins to use with hosts that don't support VST3, this crate can often be a better fit than vst2-sys, even with the remaining soundness issues.
So the recommendation in the deprecation notice could go something like this:
- To develop plugins to use with modern DAWs, use
nih-plug. - To develop VST2 hosts for your own use, use
vst2-sys. - To develop VST2 plugins for your own use, use this crate, or
vst2-sys. - To develop modern hosts, use one of the other raw API binding crates, as @glowcoil suggested.
- For any other use case (i.e. VST2 plugins/hosts not just for your own use) you are out of luck due to the licensing situation.