Rust Audio

LV2 release plan

When @Prokopyl and I started to plan the development of rust-lv2, we more or less agreed to complete the development and release it to once all I said and done. However, according to the repository statistics and comments, there are already people out there trying to use it. I think it would be better for them to have a proper release that is more or less stable instead of using a git repository, whose contents might change and break any time and that isn’t managed with semantic versions.

Therefore, I propose to have a 0.1 release when the state and worker specifications are implemented. Then, almost everything a plugin creator might want to use (except for UIs) is there. This would boost the interest in the project and give us valuable feedback or even contributions. The remaining specifications would be implemented and released using this feedback until everything is done and we have the 1.0 release.

What do you think about that?

Sounds good. I wouldn’t do it differently.

Great. There are still some things to do for that release:

First and foremost, the rust-lv2 book needs to be moved to the RustAudio group. I just don’t want that rust-lv2, which is a RustAudio project, links to a project I exclusively own. Somebody from the admins groups has to do that, please do so!

Next, we need authorization to override the lv2 crate. The current owner of that crate has already said that they would agree to hand it over if the project is more or less well developed. I will care for that.

Lastly, the state and worker specifications need to be implemented. I’ve almost finished state and already know how to approach worker, we will see how this works out.

I’m now the owner of the lv2 crate, as well as everyone in the LV2 Maintainers group. This step was rather easy.

I’ve got another question: How do we do the versioning? For a pure crate user and for the semantics sake, it would be better to have individual and unsynchronized versions for every crate. However, this would be a bit weird from a project’s point of view, since only a selection of crates in the workspace is published every tagged release.

I would personally say that the semantic versions of the crates is more important than the rather arbitrary release tags. Also, I would like to introduce git flow to the project, since a release of the crates always involves modifying the individual Cargo.tomls.

Good question. I’m not very opinionated about this; I think either is ok. Personally, in this case, I would do as you suggest and simply follow unsynchronized semantic versioning.

For the git tags, you can also specify which crate is being tagged in the tag. E.g. one git commit can have multiple tags: core 0.2.3, atom 0.1.6, time 0.1.3, …

1 Like

I’ve already released everything on Sunday, but didn’t had the time to post it here yet. Here it is: I’ve also made a larger post on Reddit.

1 Like

I @Janonard, just wanted to let you know that I appreciate your work on LV2. Development even goes so fast that I can’t keep up trying to understand what’s changing :slight_smile:

Thank you, I’m glad you like it. Thanks to @Yruama_Lairba’s work, the Worker specification is almost finished, which means that a new release is almost around the corner. I will wrap up all changes with that release.

I’m happy to announce that rust-lv2 version 0.5 has been released! Read more about it in the release notes!

Id anyone working on UI?

I am looking into it. Right now I am in a prototype stage, that I have an amplifier plugin with a simple knob to set the gain.

I am wondering if anyone has already made some experiments.

Were currently working on a new bindings crate and UI would be the next big feature. I’ve had some general thoughts on the approach we should take, but I haven’t looked into it yet and also don’t know someone who has. I’m looking forward to your prototype! :smiley: