Great system, been able to build a vst3 plugin for the rpi4+hifiberry which reads and plays a midifile 4 beats and the starts over. Midi is just a drum beat where I load a couple of sound files to play something. Also a sound recording starts after the 4 first beats to record a clip which then is looped back.
I have been trying to get some kind of input to control the plugin (run by sushi) but fail with keyboard, midi input and also OSC.
So do anyone have experience with OSC in a plugin? I tried to add OSCReceiver but fail to compile since osc was not in the Makefile in the plugin build example for the rpi4/elk os.
Hi Olof, and welcome to the forums. While building OSC support into the plugin itself is indeed possible, have you tried using the OSC features of Sushi to control parameters on the plugin? That should be the quickest way to get something going over OSC.
Which OSC library are you using for the plugin. liblo should be on the image and sdk already?
Although developing for 20+ years Elk OS and JUCE is totally new to me. I just need a push to get going understanding the basic flow with Sushi and the Audio plugin.
To understand how to send OSC message to Sushi to start with I’ve seen another thread about using oscdump #PORT. Been able to use TouchOSC from a PC to sen messages which is shown correctly. Should this work the same way if Sushi i started and can be seen in some debug log regardless of config and plugin features?
And last, do the audio plugin need to expose a certain osc frontend for Sushi to even bother send events or if OSCReceiver I setup with overrding the oscMessageReceived function all messages should be seen?
No worries Olof. I’ll take your questions one by one.
oscdump is a little tool to listen to incoming osc messages, it it very useful for debugging, the corresponding commandline tool to send OSC messages is called oscsend. To set a parameter on a plugin i sushi you would use it like this:
> oscsend localhost 24024 /parameter/plugin_name f 0.5
Though if you already have TouchOSC setup, that is much more convenient. And yes, sushi would work the same regardless of what tool you use to send the OSC messages, or if you send them from the same device or another device.
You’re correct, the osc paths must match exactly for the commands to take effect.
No, unless you want a completely custom interface, you shouldn’t add any OSC-related code to you plugin. Sushi exposes an OSC interface that allows you to set all parameter values of a plugin in a realtime-safe way.
Checking the sushi log my plugin does not list this for example:
[2022-02-21 15:36:01.090] [debug] [osc frontend] Added osc callback /parameter/main/gain
If you were able to control the gain parameter in the NeuralPi plugin, then I’m quite sure the problem is in your plugin not exposing the parameter(s) correctly. This you should be able to debug in any DAW, not just sushi, as it is not ELK-specific.
If you run it in sushi with log level set to “debug” it should list every parameter the plugin exposes like below. If the parameters you’ve added dont show up there. then something is wrong with the plugin:
[2022-02-21 17:56:38.718] [info] [vst3] Registered parameter VCF Freq, id 6
[2022-02-21 17:56:38.718] [info] [vst3] Registered parameter VCF Reso, id 7