Freeze/sostenuto project issues

sdangelo · 28 2019 14:11

Hello,

As it’s known by now (or not known enough ) I’m doing a freeze pedal using Pi+Elk. The VST is ready and tested, it’s a simple mono → mono thing with 3 parameters, and the code it’s all really trivial stuff except one malloc() and one free() call in the setActive() callback, and a roundf() somewhere. If needed, I can give you the source code (it will be publicly released under GPL3 anyway, I’d just avoid making it public before I see the prototype pedal working).

I managed to build it for Elk without issues, but I am having problems launching Sushi (Sika image v. 0.1.3).

Here’s the contents of the configuration file:

{
    "host_config" : {
        "samplerate" : 48000
    },
    "tracks" : [
        {
            "name" : "main",
            "mode" : "stereo",
            "inputs" : [
                {
                    "engine_bus" : 0,
                    "track_bus" : 0
               }
            ],
            "outputs" : [
                {
                    "engine_bus" : 0,
                    "track_bus" : 0
                }
            ],
            "plugins" : [
                {
                    "uid" : "Freeze",
                    "path" : "/home/mind/plugins/freeze-vst3/freeze.vst3",
                    "name" : "freeze",
                    "type" : "vst3x"
                }
            ]
        }
    ]
}

With the RASPA backend I get a segafult and no log or any other info, this is the whole output:

raspberrypi3-64:~$ sushi -l debug -r -c config_files/config_freeze.json
SUSHI - Sensus Universal Sound Host Interface
Copyright 2016-2018 MIND Music Labs, Stockholm
Segmentation fault

Using JACK I get:

raspberrypi3-64:~$ sushi -l debug -j -c config_files/config_freeze.json
SUSHI - Sensus Universal Sound Host Interface
Copyright 2016-2018 MIND Music Labs, Stockholm
Failed to load tracks from Json config file

and

[2019-11-27 22:54:20.888] [warning] #############################
[2019-11-27 22:54:20.888] [warning]    Started Mind Logger!
[2019-11-27 22:54:20.888] [warning] #############################
[2019-11-27 22:54:20.959] [info] [main] Setting up Jack audio frontend
[2019-11-27 22:54:20.959] [error] Sushi was not built with Jack support!
[2019-11-27 22:54:20.959] [info] [jsonconfig] Setting engine sample rate to 48000
[2019-11-27 22:54:20.961] [debug] [engine] Succesfully registered processor main.
[2019-11-27 22:54:20.961] [info] [engine] Track main successfully added to engine
[2019-11-27 22:54:20.961] [debug] [jsonconfig] Successfully added track "main" to the engine
[2019-11-27 22:54:20.961] [error] [jsonconfig] Error connection input bus to track "main", error 10

Using the dummy backend:

raspberrypi3-64:~$ sushi -l debug -d -c config_files/config_freeze.json
SUSHI - Sensus Universal Sound Host Interface
Copyright 2016-2018 MIND Music Labs, Stockholm
Failed to load Event list from Json config file

and

[2019-11-27 22:54:57.994] [warning] #############################
[2019-11-27 22:54:57.994] [warning]    Started Mind Logger!
[2019-11-27 22:54:57.994] [warning] #############################
[2019-11-27 22:54:58.064] [info] [main] Setting up dummy audio frontend
[2019-11-27 22:54:58.064] [info] [jsonconfig] Setting engine sample rate to 48000
[2019-11-27 22:54:58.066] [debug] [engine] Succesfully registered processor main.
[2019-11-27 22:54:58.066] [info] [engine] Track main successfully added to engine
[2019-11-27 22:54:58.066] [debug] [jsonconfig] Successfully added track "main" to the engine
[2019-11-27 22:54:58.066] [info] [engine] Connected inputs 0 to channel 0 of track "main"
[2019-11-27 22:54:58.066] [info] [engine] Connected inputs 1 to channel 1 of track "main"
[2019-11-27 22:54:58.066] [info] [engine] Connected channel 0 of track "main" to output 0
[2019-11-27 22:54:58.066] [info] [engine] Connected channel 1 of track "main" to output 1
[2019-11-27 22:54:58.070] [info] [vst3] Querying plugin Freeze of type Audio Module Class
[2019-11-27 22:54:58.070] [info] [vst3] Creating plugin Freeze
[2019-11-27 22:54:58.070] [info] [vst3] Plugin has 1 audio input buffers and 1 audio output buffers
[2019-11-27 22:54:58.070] [info] [vst3] Vst3 wrapper (Freeze) has 1 inputs and 1 outputs
[2019-11-27 22:54:58.070] [info] [vst3] Plugin has 0 event input buffers and 0 event output buffers
[2019-11-27 22:54:58.070] [info] [vst3] Vst3 wrapper (Freeze) setting up 1 inputs and 1 outputs
[2019-11-27 22:54:58.070] [info] [vst3] Registered parameter Dry, id 100
[2019-11-27 22:54:58.070] [info] [vst3] Registered parameter Wet, id 101
[2019-11-27 22:54:58.070] [info] [vst3] Registered parameter Freeze, id 102
[2019-11-27 22:54:58.070] [info] [vst3] No unit info or program change parameter
[2019-11-27 22:54:58.070] [info] [vst3] Looking for presets in: /home/mind/.vst3/presets/dangelo.audio/Freeze
[2019-11-27 22:54:58.071] [info] [vst3] Looking for presets in: /usr/share/vst3/presets/dangelo.audio/Freeze
[2019-11-27 22:54:58.071] [info] [vst3] Looking for presets in: /usr/local/share/vst3/presets/dangelo.audio/Freeze
[2019-11-27 22:54:58.071] [info] [vst3] Looking for presets in: /usr/bin/vst3/presets/dangelo.audio/Freeze
[2019-11-27 22:54:58.071] [debug] [engine] Succesfully registered processor freeze.
[2019-11-27 22:54:58.071] [debug] [jsonconfig] Successfully added Plugin "freeze" to Chain "main"
[2019-11-27 22:54:58.071] [debug] [jsonconfig] Successfully added Track main to the engine
[2019-11-27 22:54:58.071] [info] [jsonconfig] Successfully configured engine with tracks in JSON config file "config_files/config_freeze.json"
[2019-11-27 22:54:58.073] [info] [jsonconfig] Config file does not have MIDI definitions
[2019-11-27 22:54:58.074] [info] [jsonconfig] Config file does not have CV/Gate definitions
[2019-11-27 22:54:58.075] [info] [jsonconfig] Config file does not have any Event definitions

Please help.

Gustav · 28 2019 14:35

Hi Stefano. As your plugin is mono in/mono out only, have you tried routing audio by channels instead of busses? i.e. using the track configuration below?

"inputs" : [
    {
           "engine_channel" : 0,
           "track_channel" : 0
     }
 ],
    "outputs" : [
     {
             "engine_channel" : 0,
             "track_channel" : 0
     },
    {
            "engine_channel" : 1,
            "track_channel" : 0
    }
]

The intention is that mono tracks should be routable to a bus (and a bus is assumed to be a stereo pair) and mono plugins on stereo tracks should adapt automatically, but the code for that is not perfect yet, sorry

sdangelo · 28 2019 14:39

Hi Gustav, will try this evening. Also Stefano Zambon suggested to try making it fake stereo, will try that too.

sdangelo · 28 2019 17:07

So, routing by channels gives me exactly the same results, will try fake stereo now.

sdangelo · 28 2019 17:27

Same also with the fake stereo version.

Stefano · 28 2019 17:47

@sdangelo

could you send us a binary of the plugin? Sources and/or debug build would even be better if possible.

sdangelo · 28 2019 17:49

Sure, here or by email?
Btw, it’s derived from the helloworld example in the vst sdk, it really resembles that a lot.

sdangelo · 28 2019 17:59

btw, just tried helloworld: it seems to work with raspa but gives the same issues with dummy and JACK

Stefano · 28 2019 18:06

Whatever you prefer, mail is fine if you want to wait until releasing your code.

sdangelo · 28 2019 20:46

So it seems I found a bug in the VST3 implementation in Sushi (or so I believe): setActive() is called before setupProcessing(), which according to the documentaion should be “Called in disable state (not active) before processing will begin.” (while I’m no huge VST3 expert, all other APIs I have dealt with work like that and it makes a lot of sense).

Anyway, for the time being I have circumvented the issue in the plugin’s code and it seems to work (at least it doesn’t crash, will check the sound and controls hopefully tomorrow).

sdangelo · 29 2019 13:25

Hey guys, in less than an hour I’ve set up an open stage control configuration and could finally freeze some Led Zeppelin streaming from my mobile phone’s youtube app into the board. Only tried the fake stereo version of the plugin as I still need to “patch” the mono version to avoid the setup bug. With a debug build it consumes about 5% when not freezing, and about 12-13% when freezing. I call this a success.

Now I need to control the system without computer. I need two pots and a momentary footswitch as inputs and a few output leds.

For the pots is it ok to have one side on +5v (or should it be +3.3?), one on ground and the tap directly connected to the input pin?
For the momentary switch, do I need pullup and/or pulldown resistors? And again, should I connect to +5 or +3.3?
Is it ok for leds to be directly connected to output pins? Do I need an extra series resistor?

Thanks.

sdangelo · 29 2019 15:26

Nevermind, I’ve just seen the datasheet document, there’s everything I need (I suppose).

Gustav · 29 2019 19:00

Good that you found it. I looked through the VST3 code and indeed setActive() is called before setupProcessing(), though all of that happens before any processing, still calling them in the other order sounds like the better solution. Thanks for finding that out for us

There also seems to be something going on with the event parsing when using the dummy frontend. We’ll look into fixing that.

sdangelo · 1 2019 09:27

On my side the project is virtually completed, I could do all I wanted, but with a few problems, one of which quite serious. Here’s some feedback:

When setting the root and boot partitions as read-only (via /etc/fstab), Sensei won’t work because it wants to open a file for logging - I couldn’t find a config file or command line option to disable that. This is really critical in my use case.
Digital out state is random at boot, which means all “digital transducers” (e.g., LEDs) are into a random state until Sensei boots. Not really acceptable in a finished product IMHO.
Isn’t there a way to ask Sensei about input values/states at a given moment from the glue app? Setting all inputs to continuous mode is not really a great option, and neither is asking the user to touch everything after boot.
The supplied systemd sushi.service does not (always?) work, I had to change current directory to /home/mind.
I couldn’t control Sushi via gRPC from my computer (to develop the glue app faster), was it me or is it not enabled or blocked?
I think a nice addition would be to allow the configuration of OSC messages formatting and per-parameter OSC destination in the Sensei configuration file, as it could allow avoiding or greatly simplifying the glue app (e.g., I could just set the base path to “/parameters/freeze” and not have “analog” and “digital” before parameter names, then specify the Sensei OSC port and I wouldn’t have to deal with inputs in the glue app).
I know it’s early for that, but please… documentation.

Other than that, Elk really rocks!

Stefano · 1 2019 16:37

Ciao @sdangelo,

How are you launching SENSEI?
A quick workaround is to just set WorkingDirectory in a SystemD unit to a path where you can write. For example, we typically leave /udata in R/W and then use something like:
WorkingDirectory=/udata/logs/sensei, or if you want to have everything RO, you can use /tmp.

Not much we can do about this without a HW revision… but the Elk Pi is not a good fit for a “finished product” anyway, depending on your definition. For those, we recommend designing a new PCB using the RPi3 Compute Module.

I know it’s possible at least on some platforms since we use it, not 100% sure about SENSEI on the Pi. Maybe @Gustav or @Sharan can help you here.

How does it fail when it’s not working? Can you paste the output of journalctl -u sushi?
We almost always launch SUSHI from other directories than /home/mind.

Yep, bummer, it’s currently blocked :(.
Will fix it for next release.

So IIRC what you mean, you would like to have the option to remove the parts /analog/ and /digital/ in the OSC paths created by SENSEI?

sdangelo · 1 2019 19:41

Ciao @Stefano ,

When setting the root and boot partitions as read-only (via /etc/fstab), Sensei won’t work because it wants to open a file for logging - I couldn’t find a config file or command line option to disable that. This is really critical in my use case.

How are you launching SENSEI?

A quick workaround is to just set WorkingDirectory in a SystemD unit to a path where you can write. For example, we typically leave /udata in R/W and then use something like:
WorkingDirectory=/udata/logs/sensei, or if you want to have everything RO, you can use /tmp.

Ok, now it works, problem solved (I didn’t know it was trying to write in the working directory).

Digital out state is random at boot, which means all “digital transducers” (e.g., LEDs) are into a random state until Sensei boots. Not really acceptable in a finished product IMHO.

Not much we can do about this without a HW revision… but the Elk Pi is not a good fit for a “finished product” anyway, depending on your definition. For those, we recommend designing a new PCB using the RPi3 Compute Module.

Fair enough, sometimes I get carried away and forget the dev board is not for meant for production.

The supplied systemd sushi.service does not (always?) work, I had to change current directory to /home/mind.

How does it fail when it’s not working? Can you paste the output of journalctl -u sushi?
We almost always launch SUSHI from other directories than /home/mind.

IIRC the default working directory is non existant on the fresh image. However it works when launched from any existing directory without complaints (even in ro mode, anyway now I set it to /tmp).

I think a nice addition would be to allow the configuration of OSC messages formatting and per-parameter OSC destination in the Sensei configuration file, as it could allow avoiding or greatly simplifying the glue app (e.g., I could just set the base path to “/parameters/freeze” and not have “analog” and “digital” before parameter names, then specify the Sensei OSC port and I wouldn’t have to deal with inputs in the glue app).

So IIRC what you mean, you would like to have the option to remove the parts /analog/ and /digital/ in the OSC paths created by SENSEI?

Yeah, for example, plus the ability to send messages from different sensors to different OSC servers (actually, even more generic would be to have multiple Sensei backends at once and choosing for each sensor/transducer one or more backends data should be sent to or received). In other words, some mechanism to have Sushi and Sensei talk to each other via OSC without writing code for simple parameters could be handy.

Stefano · 9 2019 11:59

Moved to public plugin development section.

Regarding the RO / RW settings, we prepared some utility scripts in the next release to help you with this:
https://elk-audio.github.io/elk-docs/html/documents/working_with_elk_board.html#elk-system-utilities

sdangelo · 18 2019 12:51

Two more quick questions:

Is there a way to disable rootfs swapping when often unplugging too early?
(I could measure this but you probably know already) - if I put no jumpers on the 0/+10 dB pins, what is the outcome?

Alberto · 18 2019 13:43

@sdangelo if you don’t put the jumper on the 0/+10dB pin you will be in the +10 dB configuration, as reported here

Sharan · 18 2019 13:51

Yes it is possible but this would mean that we would have to change the uboot script (boot.scr) in /dev/mmcblk0p1. The script has a counter which is incremented each boot and is reset after every successful boot. If you have 10 unsuccessful boots in succession, the bootloader will swap the partition.

If you really need it, we can generate a uboot script which does not increment this counter. However, this will inhibit the bootloader from detecting a successful boot.

If you do find yourself in a situation where the rootfs has been swapped, you can always use the utility tool elk_system_utils as described in

https://elk-audio.github.io/elk-docs/html/documents/working_with_elk_board.html#elk-system-utilities

Do let us know if you want an uboot script which does not implement that counter