rust-lv2: No support for Ardour - No support for inPlaceBroken

I used the amp example from the docs and discovered that Ardour 5 to 6.3 do not support the inPlaceBroken feature.

After loading Ardour I get this warning and Ardour just ignores the existence of the plugin.

[WARNING]: Ignoring LV2 plugin "amp" since it cannot do inplace processing.

Tested on Linux amd64 platform. The plugin works with Carla, and carla.lv2 can be used from within Ardour so it is still kind of usable. But it’s a bit sad I would have to go via Carla.

I understand the rationale from the rust-lv2 user guide for not supporting it, but I would gladly accept some unsafe code in the processing function itself.

Otherwise I would have to look into writing the DSP code in Rust without rust-lv2 and try to use it from a C wrapper library.

So I would suggest three options to deal with this:

Don’t state in the README that Ardour is supported.
Allow plugin developers to have some unsafe’ness.
Implement the C side to handle inplace edits of the buffers and copy either the input or output values to an extra buffer. The performance hit is better than no support at all. That could maybe be done by providing an InputPort<AudioCopy> port type - but I am not too deep into the internals of rust-lv2 and the unsafe side of Rust programming.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (11 by maintainers)

Most upvoted comments

Seems i missed an interesting discussion here.

Nobody considered to allow some unsafeness for plugin developers ? In practice, it just mean giving access to the ports as raw pointers. And as long those pointers aren’t casted to reference, we (developpers included) don’t have the rust undefined behavior issue of having ‘&’ and ‘&mut’ reference to the same data.

I know it’s not ideal, since we defer to developer the responsibility of not overwriting input data before using it because of pointer aliasing. But i also think it’s not easy to design an API guarantying this while being convenient and efficient for most use case and we may wait a long time before having it.

YruamaLairba on Feb 26, 2021

@PieterPenninckx wrote:

Another idea is the following. When the buffers received are longer than the capacity of the Vec in ClonedAudio or ClonedCv, to split them into parts that are small enough and to call run multiple times, once for each part. The upside of this approach is that it doesn’t require the host to support bounded block length, the downside that I see is that it may affect other things as well, e.g. you need to split sequences of midi events.

You’ve already said it: If we would follow this idea, we would need to time-split Atom Sequences, containers for other atoms with time stamps. However, since events in a sequence may not be in order, this would require us to copy chunks of unknown size from one place to another. This can only be done properly by allocating new memory, which is exactly the thing we are trying to avoid. Therefore, this idea sadly doesn’t work out.

Also, I wouldn’t use any LV2 extensions in general to manage ports in the lv2-core crate. It is supposed to be the bare minimum for any plugin and plugins that only use this crate should be able to run even with the most minimalist hosts. Sure, these extensions are very useful for plugin authors and hosts should support them if possible, but we shouldn’t require every plugin and therefore every host to use/support them.

All in all, I still think that the most elegant solution is a Vec<f32> that stores the input frames and is re-used. True hard-RT environments are rare and I think we can safely accept the “risks” of not supporting hard-RT and in-place work at the same time.

Janonard on Nov 21, 2020