Continuing the discussion from Elk Audio OS 0.9.0 (major SUSHI update):
Hi @frederic!
Regarding the VST3 plugin:
It could well be that the uid is incorrect. Also likely, your plugin is not x-compiled properly, or (also very likely) the sub-folder structure is not as expected for VST3.
To figure out which it is do take a look at our example VST3 configurations if you haven’t already. Currently the examples using VST3 happen to be for Linux desktop, but may still be of help.
In the Sushi repo look at config_play_vst3.json, or in the elk-examples/mda-jx10-vst3 - both configuration files are identical.
Your path looks correct, but the uid, and perhaps the folder structure under SourceSamples.vst3 bears double checking. Look at the structure for the mda vst3 to check - these are part of the sdk.
The uid is the unique plugin name, which indeed may not be straightforward to deduce - many plugins can be in the same binary. For the MDA VST3’s I’ve gleaned them from the source code, in the mdafactory.cpp file, the fields labelled “name”.
As for the sensei config, our Blackboard examples are ported and verified to work with this release - is it a Blackboard you have? Then using these first will probably be a good step towards fault-seeking. The sensei log file should be appearing in /udata on your Elk Pi.
Best,
Ilias of Elk
1 Like
Thanks Ilias, I’ll investigate and report back.
About the VST3, the folder structure seems fine, also the config file I modified it from the examples. The uid must be the problem then, but because it appears later in the logs I thought might be something else as well. I’m not use how I can get the UID for the vst3, but I’ll ask in JUCE forums and test.
About sensei, I think I’m using a configuration from the examples, but I’ll double check. Also I’ll see if there are any logs in /udata
thanks Ilias,
frederic
Hi,
regarding the VST3 uid: that is very likely the issue, SUSHI needs to know it.
IIRC, in Juce it is automatically assigned to the “name” given to the AudioProcessor class that will be wrapped as a VST3 plugin, so try to use that.
The AudioProcessor class name does not seem to work. I’ll keep on trying other stuff. I think I have a problem with MIDI as well, I’ll ask in another thread.
Digging a bit more I found this bit of sushi code https://github.com/elk-audio/sushi/blob/8c1ce6e369aaa29496234e004f35e017c786cdea/src/library/vst3x/vst3x_host_app.cpp#L306 which should be logging (if I understand correctly) the different plugin uids/name bundled in the .vst3 plugin container. I don’t think sushi reaches here in my case, so the problem is that the .vst3 container generated by JUCE does not seem to be ˝correct". Did you ever tested compiling a vst3 plugin with JUCE 6 and loading it to sushi?
Hi frederic, do you still get log errors like the one you posted here? Elk Audio OS 0.9.0 (major SUSHI update) In that case your’re right in that this error happens when loading the shared library and it doesn’t even get to the point where it scans the binary for plugins. Which, as you mention, should print all the tested uid:s in the log.
If you look in the plugin.vs3/Contents folder. Whats is the architecture folder named? It could be a cross-compiling problem where this is named incorrectly. At least we have had such problems before.
1 Like
HI @Gustav, the folder is called arm64-linux, I guess this is right?
No, unfortunately that is not correct. I just verified with our resident Linux expert here. Try changing the folder name to “aarch64-linux” and see if that works. This is a cross compiling issue with the vst sdk. IIRC we had a workaround, but perhaps it doesn’t work with juce 6.
1 Like
I’ll try that later and report. Thanks!
1 Like
hi,
renaming the folder to aarch64-linux did the trick! the uid I used was the same name as in the .so file inside aarch64-linux folder. So I was finally able to load the VST3 plugin made with JUCE6, hurray!
however the sensei problem I’m still having it. I’m on a blackboard, using the configuration of the example https://github.com/elk-audio/elk-examples/blob/master/blackboard/common-files/sensei_config.json and when I run /usr/bin/sensei -f /home/mind/source_sensei_config.json I get Failed to initialize, check logs for details. Exiting.... When this happens, a file named log is created in the current working directory and it has these contents:
[2020-12-10 22:02:50.208] [error] [Shiftreg Gpio] Failed to open driver. Error -1
[2020-12-10 22:02:50.208] [error] [Shiftreg Gpio] Failed to init driver
[2020-12-10 22:02:50.208] [error] [eventhandler] Failed to initialize hw backend
any ideas what could be going wrong?
1 Like
ok, I sorted it out. The issue was with permissions for the mind user. After giving full sudo permissions to mind the problem stopped and I can run sensei now.
2 Likes