I have a VST2 synth plugin running on ElkPi which modulates signals based on channel pressure and polyphonic aftertouch messages. This works nice when running in my desktop computer as a plugin, and responds correctly to aftertouch messages (both channel pressure and poly at). however, when running on sushi it looks like these messages are filtered out, even if I configure the midi input with “raw_midi”: true as instructed in the docs (Sushi Configuration — Elk DevKit documentation).
can someone confirm if midi filtering is happening? and why? I want all the midi messages
Hi Frederic and thanks for finding out. It doesn’t work for me either and indeed appears to be a bug in Sushi. AT and poly AT should be forwarded to the plugin, regardless if ‘raw_midi’ is enabled or not.
We’ll make a note of the bug and hopefully should have it fixed in the next update.
/Gustav
Hello from Cologne ,
i chime in my interrest in Sushi as a midi controllable headless daw ,
I want all the midi cc ´s , too … , when will be the next update coming ?
Hi berndkeul. Midi cc’s are already working, it’s only the aftertouch commands that are affected by the bug mentioned above. If you use ‘raw_midi’ you will get all the midi cc’s directly to your plugin, tough I would suggest you map midi cc messages directly to parameters instead.
At he moment we’re putting all our development effort into Aloha, so there is no timeplan for when the next Sushi release will be out unfortunately. Though it will be quite a big release.
Hello Gustav , thank you for your fast response, I will checkout Aloha first , and aftertouch comes when it comes , I have 3 Roli Seaboard Blocks , so will have good use for that …
Hi,
So I guess this will take a significant amount of time. Maybe someone at ELK could provide a hint about where to look in the code to fix that? I’d try to fix it and compile sushi with the sdk if that is even possible
The next release of Sushi will likely contain a reworked and expanded grpc interface with many more possibilities for dynamically adding/removing tracks, plugins, midi and audio configurations. It’s a quite big release and as mentioned, we’re working hard on Aloha so we can’t give a release date for it.
thanks for the tip, I’ll try that!
what would be the recommendation for building sushi for elkpi? should I try with the cross-compilation sdk or should I try doing it in the board itself?
If you have a couple of GB to spare for the cross compiling sdk I would recommend you to install it to be able to cross-compile. Building on the board is possible but expect 15-20 minute build time for a fresh release build of Sushi. Not very fast turn around for testing.
Hi @frederic,
yes you should be able to build SUSHI using the SDK (I’m doing regularly).
However, there might be one step that requires some gRPC stuff installed on the host computer - it’s on our list to avoid this dependency. It should be relatively easy to add it if you have a VM / native Linux setup, not sure how easy if you’re using Docker though. Do you need gRPC support? Otherwise, you can build by disabling it on CMake and it should be more straightforward.
I could cross-compile sushi from mac using the sdk normally, just like I’d do for plugins. To facilitate things I use a python fabric script that I run directly from macOS so the process is really smooth. You’ll find instructions in the repository.
I consider poly AT to be a necessity, and am continually nursing my ageing Roland A-50 and A-80 whilst patiently waiting for somebody to manufacture something better. Although I am currently experimenting with a view to making a board for retrofitting to fatar keybeds.
Of course I look forward to Elks official updates, but in the meantime, I will certainly be checking out your work.
yeah, we definitely need better polyAT support across the industry. My patch for ELK’s sushi has been working fine so far, I hope it works for you as well,
