I just spent some time looking at the parameter control API for VST (e.g. IEditController), and read the top level docs on Sushi. It’s still not at all clear to me how a VST plugin running under Sushi would be communicated with by an outside controller using gRPC.
Is there a good explanation of that anywhere?
Hi! To control sushi using gRPC I would suggest taking a look at this python library. It provides a simple interface to interact with plugins and tracks. If your goal is to mirror the interface of a plugin you can embed this C++ library in to the source of the plugin interface. To use the sushi gRPC libraries you also need the sushi_rpc.proto file.
If you just want to control some parameters from the command line the easiest way is to use oscsend which is already installed on the board with something like oscsend localhost 24024 /parameter/'plugin_name'/'parameter_name' f 'float value to set parameter to'. Hope this helps 
Hi @Jandyman,
another suggestion would be to launch SUSHI with the --dump-plugins flag. It will generate a JSON file with info about the parameters in the chain specified on the configuration passed, both names for the gRPC API and OSC paths.
SUSHI abstracts away any internal definition used by the specific API like the IEditController in VST 3 that you mentioned, since it needs to offer a uniform API to the final users.
Both replies are super helpful. I think I get the gist. I think I’ll be able to both generate the appropriate VST for my own work, plus control existing ones over BLE, once the BLE stuff and a simple iOS example make it into the open-source Elk world. That will be an exciting day indeed.
I still need to study gRPC and understand how a proto file gets “compiled” and so forth, but that appears to be a separate matter.