[Elk Pi] Faust to VST - OSC troubles

ValC · 4 May 2022 08:47

I have to apologize, I didn’t read your post, where you indeed only talked about output parameters handling, carefully enough.

In Reaper, output parameters are well displayed in the default UI as faders, moving correctly. Interacting with these is however still possible, but this is also the case for the output parameters of Reaper’s JS plugins. In Reaper default UI of a Faust/JUCE/vst3 plugin, output parameters are displayed but not responding at all, unlike in their custom UI where they display properly.

I may add that Reaper reflects interaction with output parameters by sending OSC messages just as if they were input parameters.

In Ardour, output parameters are displayed in the default UI as well, but the corresponding elements do not move on their own. They seem to update to incoming values by interacting with them, but freeze right after releasing the mouse button.

Valentin

Ilias · 4 May 2022 09:09

That’s great, then you know that your plugin does output - the subsequent step would be to ensure that you get OSC out from a plugin in Sushi - which doesn’t have to be yours, but can be a peak meters plugin - or even the Sushi internal meter plugin!

We have a configuration you can test with which already has this enabled:

github.com

elk-audio/sushi/blob/master/misc/config_files/config_arp_peakmeter_osc_broadcast.json

{
    "host_config" : {
        "samplerate" : 48000,
        "tempo_sync" : "ableton_link",
        "playing_mode" : "playing"
    },
    "tracks" : [
        {
            "name" : "main",
            "mode" : "stereo",
            "inputs" : [ ],
            "outputs" : [
                {
                    "engine_bus" : 0,
                    "track_bus" : 0
                }
            ],
            "plugins" : [
                {
                    "uid" : "sushi.testing.step_sequencer",

This file has been truncated. show original

Edit:
The above assumes the plugin "path" : "/usr/lib/lxvst/mda-vst3.vst3", is available, which on your system it may not be, but I suppose you know as much and can adapt that line for the config to wotk.

I think you did mention that you had OSC out working for other plugins, but still, it’s always good to take one step at a time.

With that working, if you then replace the internal plugin with yours, changing the config file accordingly, I expect it should work, no?

Best,
Ilias of Elk

ValC · 4 May 2022 10:11

I’ve run this configuration and oscdump shows level_0 and level_1 incoming values from the peak meter.

After a quick modification of my test plugin - that hadn’t any audio input but a signal generator instead - now being a simple stereo meter, I tested it back in Reaper, then replaced Sushi peak meter with it. oscdump now doesn’t show any incoming parameter values.

Edit: I can send Faust code, generated C++, built plugins or whatever that could help, but you all may have kindly spent enough time to help solve an issue for which a workaround has been found!

Valentin

Ilias · 4 May 2022 12:15

@ValC

I realized the absolute sure-fire way to ensure the OSC frontend sends OSC parameter output, is to enable “debug” logging, and check to log file directly!

So, when I ran Sushi with the options -j --connect-ports -c /home/ilias/workspaces/sushi/misc/config_files/config_arp_peakmeter_osc_broadcast.json -l "debug" -L "/tmp/logs/sushi_OSC.log", the log file contained several entries as follows:

[2022-05-04 13:51:14.029] [info] [main] Listening to OSC messages on port 24024. Transmitting to port 24023, on IP 127.0.0.1.
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/link_channels
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/peaks_only
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/update_rate
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_0
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_1
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_2
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_3
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_4
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_5
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_6
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_7
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_8
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_9
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_10
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_11
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_12
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_13
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_14
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/level_15
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_0
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_1
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_2
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_3
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_4
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_5
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_6
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_7
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_8
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_9
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_10
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_11
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_12
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_13
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_14
[2022-05-04 13:51:14.030] [debug] [osc frontend] Added osc output from parameter peakmeter/clip_15

(…)

Then while running, the log contains many entries as follows:

[2022-05-04 13:51:14.587] [debug] [osc frontend] Sending parameter change from processor: 3, parameter: 4, value: 0.8049917
[2022-05-04 13:51:14.630] [debug] [osc frontend] Sending parameter change from processor: 3, parameter: 3, value: 0.80246043
[2022-05-04 13:51:14.630] [debug] [osc frontend] Sending parameter change from processor: 3, parameter: 4, value: 0.80246043
[2022-05-04 13:51:14.673] [debug] [osc frontend] Sending parameter change from processor: 3, parameter: 3, value: 0.8008326
[2022-05-04 13:51:14.673] [debug] [osc frontend] Sending parameter change from processor: 3, parameter: 4, value: 0.8008326

We will be releasing a new version of Sushi in the near future, which contains several improvements, and which might affect this behavior. So if you already have a workaround that you are using for now, perhaps the most time effective way for you could be to test again when we have made the new Sushi release?

If you have the files handy however, you could always attach them to an email, and one of us can take a look at some point to see if this is a bug with our code - If you have already built plugins (VST3 and LV2) for Ubuntu that would be useful for example, or if you have them for the RPi4. In that case, send the email to info@elk.audio mentioning it is for us developers!

Best,
Ilias of Elk

ValC · 4 May 2022 13:41

Thank you @Ilias

Yes, when things go wrong, the log is the first place I take a look at!

OSC output parameters seems to be properly set up for my plugin:

[2022-05-04 13:16:32.781] [info] [osc frontend] Added osc output from parameter peakmeter/Right

But no “Sending parameter change” entry. Instead, many of these:

[2022-05-04 13:16:32.799] [debug] [vst2] PLUG> HostCallback (opcode 42)
index = 0, value = 0x0, ptr = 0x0, opt = 0.0

Sure, I’ll be looking forward to try things again with the next version, and I’m sending you a mail anyway!

Thank you very much!
Best,
Valentin

Gustav · 5 May 2022 09:29

Thanks for posting this log excerp Valentin, this makes it much clearer what is going on here.

What is happening is that the plugin is signaling an audioMasterUpdateDisplay notify to the plugin (opcode 42) which is used to tell the host to reload parameter and program names from the plugin. We don’t currently support this in Sushi.

What sushi expects is instead an audioMasterAutomate (opcode 0) which is used by the plugin to tell the host that a particular parameter value has changed. If using the bare vst 2.4 sdk, this is triggered by a call to setParameterAutomated().

This is a VST2.4 plugin, it is built with faust tools? I’m not familiar with that code so can’t help you with that, but look through what vst functions are called when changing parameter values. It seems odd that it should be using that function to signal parameter changes.

Ilias · 5 May 2022 12:12

In addition to Gustav’s response, I did a test today and can confirm that specifically for LV2, we do not correctly process the output of Control parameter changes from LV2 plugins.

We do support OutputPorts, but only for MIDI, and in your case the output port is a ‘ControlPort’.

I also see that the plugins we’ve tested with do not have that combination, of Output Control ports, which explains why we haven’t caught this before.

Given your plugin a fix is straight-forward however, thank you for that!

Best,
Ilias of Elk

ValC · 5 May 2022 18:17

You are very welcome, @Ilias! Glad to have “brought my little stone to the building”.

Thank you @Gustav, I reported this to Faust developers!
This vst2 plugin was build with Elk’s Faust vst template, and it showed similar behavior when built directly with the faust2faustvst tool.

Best,
Valentin