Rust Audio

Project suggestion: Cargo extension for LV2 plugins

I’ve recently started to create some LV2 plugins for my personal use and also to test the usability of the framework. While doing so, I’ve stumbled across some inconveniences. The root of it all is that a complete LV2 plugin isn’t only a shared object, it’s a folder with Turtle configuration files, possibly multiple shared objects and other resources. This means that a LV2 plugin project requires an additional build system apart from the normal Cargo system to assemble all files into a folder and to install them. However, this also makes creating a plugin from scratch a bit more cumbersome than simply creating a new crate. I’ve collected the things I’ve found in a list of user stories:

  • I as a plugin creator want to create a new plugin project from scratch to implement my ideas.
  • I as a plugin creator want to compile the plugin code and the resources into one folder to test the deployment.
  • I as a plugin creator or plugin user want to install a plugin from the source project to run and use it.
  • I as a plugin creator or plugin user want to run the plugin from the command line to test it.
  • I as a plugin creator want to package my built plugin in order to ship it to other users.
  • I as a plugin creator want to automatically insert the name of the shared object in the plugin’s manifest so I don’t have to do it manually for every operating system. (Shared objects have different naming schemes depending on the operating system).

From my point of view, the simplest way to implement these user stories is to create a extension for Cargo, let’s call it cargo lv2, that does exactly that. There could be sub-commands to create a new project, build it and install it in a certain directory. Some new information would be required, though, which would be stored in the Cargo.toml. Maybe, if the host framework would become a thing, we could also add a custom run command that would host the program like jalv does.

What do you think about that idea? Did I miss any user stories and is there anybody interested in creating such an extension? I don’t know if I will have the time to maintain it, but I would love to contribute!

I like the idea, but I would postpone it. One reason, as you mentioned, is that you need time to maintain it. The other reason is that I think the ecosystem around cargo is still evolving and would make things like this more easy in the future (e.g. this issue may help us in the future, though I’m not sure if and when this will land).

Things we could do now already, without needing a cargo extension:

  • use pre-build commands with files
  • create a hacky shell script for packaging (as vst-rs already does)
  • promote a different crate organisation for plugin creators: put the meat of the separate crate (which is a good idea anyway), have one crate (depending on the previously-mentioned crate) that can be used for quick testing (e.g. where cargo run does the audio processing immediately on some pre-defined data) and one crate for the actual plugin
  • use kickstart or similar to help initiating a project

Weird, i looked on discourse since this message have been posted, but i only see it now.
What you describe is typically what a build automation software can handle, so i think it wiser to use this kind of tool if possible, especially when you can find one as cargo plugin, like cargo make (i didn’t tested it, i’m still using stupid .sh script for some task). In this way, you just have to provide a lv2 project example using this tool.

Yes :wink: , I as a plugin creator, i want to strip the executable when building a release (as i know, it’s not handled by cargo)

Yes, cargo make seems to be a useful tool for that! :smiley: I will investigate on how to use it for plugins.

However, I don’t quite understand what you mean with “strip the executable”: Firstly, LV2 plugins aren’t executables, they are shared objects/dynamic libraries, and secondly, the built libraries are already pretty small when built with --release, about 250-300k. Maybe you can strip something of that, but I don’t think this is necessary. Even if it’s necessary, I would consider it as a part of the “install a plugin” or “package my built plugin” user story :confused:

Yes, sorry, i was meaning “strip the binary”

Not here, in build release it’s more around 2-3M. Maybe you have a special configuration that already “strip” during the release building, because i reach the 250-300k after the stripping.

I found another interesting way called cargo xtask. It’s not a crates or a cargo plugin, it’s a trick relying only on rust and cargo. The idea is to simulate a cargo plugin local to the project by embedding a special crate and creating an alias that “cargo run --” this crate.

The main drawback is you have to write a CLI application, but as benefits, everything is self contained, no need for extra tools, heavily portable, and people can pick and modify your “xtask” source to fit their needs.

I use stable Rust 1.42.0, installed via rustup, running on a NixOS (x86_64 Linux), and I’ve run cargo build --release on the examples. The generated libraries are found in target/release.

What are you using?

I also use Rust 1.42.0 installed via rustup on Debian 9 (x86_64 linux), but that not what i was thinking. I think you may have somewhere a .cargo/config that override the default behavior.

I retry the amp example in release mode, 3,8M before the strip 1M after O_O. Weird, it’s huge.