I’m making a pitch scaling sampler with JUCE and I need a parameter that stores the file path to the current sample. I’ve seen that internal plugins can have properties that are exposed in OSC or gRPC. How can I expose my file path so it’s recognized and exposed by sushi as a property ?
Cheers,
Val.
Hi Valentin!
Unfortunately right now, there is no API over which plugins created with JUCE can take string parameters over the plugin API - if they very recently added one I’ve missed, Sushi does not support it. Maybe that will change now that they’ve started supporting LV2? Probably not any time soon if they stick with the “lowest common denominator” of parameter controls.
So the solution to this is to implement your own OSC / gRPC / JsonRPC server inside the plugin, which can receive a file path that way.
The most straightforward way, given that you already use JUCE, is to use JUCE’s OSC library - that way you don’t need to add external dependencies. But depending on your requirements perhaps gRPC is a better choice.
Mine and Gustav’s ADC talk happen to be exactly on this topic, so if these technologies are new to you it is a good resource for you to make an informed decision based on your needs:
Best,
Ilias of Elk.
Thanks for the reply ! Implementing it with the JUCE OSC module was indeed the workaround I thought about. If I’m not mistaken, this would create two OSC server instances: one for sushi and one for the plugin. I’m not entirely familiar with OSC, but is there a way to have a single server instead ?
Cheers,
Val.
There’s no way of having a single server in this case, no.
In theory OSC is transport layer independent, but in practice it’s always used over UDP 99% of the time - the other 1% being TCP. I don’t remember if the JUCE implementation even supports the latter since it’s such an edge-case.
You COULD use the same UDP broadcast port, so that both / all your servers receive all messages, but there’s no big advantage to that.
These choices also depend a lot on the context you’re working in. I’ve been assuming a headless scenario for all my advice here, as per the youtube talk.
Normally in that case you’re on an embedded device, so you can also predict which UPD ports will be available - if you’re on e.g. MacOS / desktop linux, you’d need to also make sure that the UDP ports you receive on are available.
Best,
Ilias of Elk.
Thanks !
I’m indeed developing for an embedded target, in headless mode. I’ll probably go with the same port, since it seems to be easier to interface with a OSC client like Open Stage Control.
No problem - just in case you didn’t know, in that case you’ll need to use UDP ports specifically reserved for multicast messages.
Best,
Ilias of Elk