LV2 Plugin Atom messages

Elk Audio OS
1

First of all I would like to thank you for publishing such great software as open source, I am new to the Elk audio OS and starting to learn about all the great features.

I am currently exploring Sushi. I want to use an LV2 plugin (LSP impulse response mono plugin). I was able to successfully configure Sushi to run the plugin. Most of the controls are in the gRPC API. However on of the most important configurations is the Impulse Response .wav file. In a DAW this file can be set in the UI of the plugin. The LV2 plugin supports setting the filename also via an Atom LV2 Patch message. I was wondering, if sushi would support sending Atom messages to LV2 plugins?

2

Hi laenzi and welcome to the forums. No, there is no support for complex LV2 Atoms in sushi at the moment. Only floating point parameters are supported.
Though as serialized programs are supported over gRPC, maybe that could be a viable way to set the path to the ir file? You would have to construct the program/preset file yourself though.

3

Thank you very much, Gustav for your valuable response.

I have experimented a bit further with the LV2 plugin, and found a way by adding state to the to plugins manifest (the plugin supports reading LV2 state extension).

This workaround looks very feasible for now, however I would like to investigate also the program/preset change via gRPC. Is this the standard LV2 preset extension that is exposed via gRPC?

However, before digging down that route, I have another issue now with Sushi, where I am stuck: I don’t get any sound output from the plugin when using it in Sushi.

I was able to successfully run exactly the same plugin with jalv. I can see the log output with jalv, However, in Sushi, the log output from the plugin does not seem to be routed to the sushi log file. Does sushi support the LV2 logging facility http://lv2plug.in/ns/ext/log?

I am asking this, because the LV2 log output would help me debugging the issue.

4

Hi laenzi

No, the logging extension is not mapped to the sushi logger, unfortunately.

The processor state exposed over gRPC is a general object that can be used both to store a list of parameter values, and/or pack binary data, depending on what the plugin format requires. In the case of LV2, we use lilv to pack a serialized state into it. Though iirc, that serialized state is pretty much plaintext.

I think the easiest way would be to read the state from the plugin and look at the binary_data member in the received ProcessorState object, and go from there.

On the topic of no sound, do you get sound with other plugins? If you’re using the jack audio frontend you need to explicitly connect the output ports to something (or run with the –connect-ports flag).
If it’s only with this plugin, then I would recommend running with sushi with –log-level=debug --log-flush-interval=1 and watch the logs if something comes up.

5

Hi Gustav

After setting the Log level to debug, I can now see the logs from the LV2 plugin

[2022-12-23 10:09:05.384] [debug] [lv2] LV2 Error: ......

so it looks like there is some basic LV2 logging implemented in sushi. Just the log params (similar to printf) are not interpreted, but thats a minor problem, with this basic log facility, I guess i can debug what is going on.

With regards to the sushi/jackd setup: That should not be the problem, why I don’t get sound from the plugin. When I replace the LV2 plugin with the example Amp plugin, I get sound.

I suspect that - unlike jalv - sushi does not handle or implement the state @prefix state: <http://lv2plug.in/ns/ext/state#>. extension and therefore does not initially apply the the state mentioned in the plugin manifest?

I yet have to experiment with the gRPC state handling.

6

Unfortunately, I don’t see any of the state that I want to influence in the gRPC api:

grpc_cli call localhost:51051 --protofiles=sushi_rpc.proto GetProcessorState "id:1"
connecting to localhost:51051
bypassed {
  has_value: true
}
parameters {
  parameter {
    parameter_id: 2
  }
  value: 1
}
parameters {
  parameter {
    parameter_id: 3
  }
  value: -2.98023224e-08
}
parameters {
  parameter {
    parameter_id: 4
  }
  value: 0.909090877
}
parameters {
  parameter {
    parameter_id: 5
  }
  value: 1
}
parameters {
  parameter {
    parameter_id: 6
  }
}
Rpc succeeded with OK status

It looks like only the parameters are exposed. My current understanding is, that sushi’s processor state is not what is considered as LV2 state (as described in LV2 State)

I am currently out of ideas… maybe the easiest would be to change the the plugin to somehow change the files via program change?

7

For the logging problem, I have created a PR. HTH

1 Like
8

After some more debugging I have one reason, why there is no audio output:

The LV2 plugin uses scheduler to load the the audio sample (it makes sense to not run that task in the realtime thread)

However, for some reason, the scheduled task ins never executed by sushi.

I have to mention that I am running sushi on ubuntu with jackd

After debugging a bit further I found the reason why its not working.

Sushi has a restriction for the maximum scheduler atom message size which was exceeded by the LV2 plugin that I am using.

After changing it to 256 bytes, the plugin started to work.

I would suggest to make this value configurable (ideally at runtime).

Best Regards and Happy Christmas

1 Like
9

Hi laenzi. And many thanks for taking the time to debug this and write detailed reports. I have written internal bug reports for the lack of logging parameters and for the atom message size. Both should be pretty easy fixes.

As for the state. If you dump the entire sushi state (all tracks and processors) using the save_session() function in the SessionController. Do you then get the state containing a binary state?