it’s again the time of the year when we consolidate Elk’s work into our public open-source releases.
This time we felt that the amount of changes, and the maturity of the system are enough to finally justify a version bump to 1.0. Elk Audio OS 1.0 will be released in November shortly before the Audio Developer Conference 22, where we’ll be present as sponsors and presenting two talks and a workshop.
For now, we’re ready to push Sushi 1.0.0 and the libraries related to its ecosystem.
Notable new features
You can now run Sushi on a macOS computer, in addition to the already supported Linux platforms. This makes it very easy to prototype embedded audio products entirely on your computer, solving most of the problems before moving to the target embedded hardware. We chose cross-platform libraries for audio & MIDI support (Portaudio and RtMIDI), since we plan to support Windows as well the next year.
Sushi now has a very flexible way to handle state save & reload: you can save plugin binary state, partial parts of the audio graphs, or the entire session in an efficient binary format. There are gRPC endpoints to access all of these new features.
On top of the already existing audio graphs made up of tracks & processors, there are now “pre” and “post” tracks that can be used to process the engine channels before they are dispatched to/from the audio graph. This is useful for example if you want to do some pre-processing on the input channels (e.g. noise gating, EQ), or if you want to do post-processing on the channels as they are sent to the soundcards (e.g. peak-metering, limiter).
The build system has been significantly streamlined, we now use vcpkg to handle the complex third-party dependencies such as gRPC.
TWINE, elkpy and elkcpp have also been updated. The official Elk Audio OS documentation reflects the new changes, too.
We provide the traditional Linux AppImage x86-64 and, this time, binary releases for macOS x86 (10.15 or later) and arm64 (11.0 and later). The binary releases now contain the MDA plugins and a set of configuration files that can be run straight away from the download folder.
The macOS binaries are signed & notarized, however you would have to clear the quarantine bit that will be set if you download them from a browser. You can do that with:
$ unzip sushi-macos-[arm64|x86].zip $ xattr -rc sushi
Full release history
HISTORY.md in the repository:
- clang 13+ support
- gcc 10+ support
- macOS support
- VST2 & VST3 bundle support for macOS
- Portaudio frontend
- RtMIDI frontend
- MIDI clock output
- Processor state save & reload
- Plugin binary state setting
- Session state save & reload
- Refactor track modes w.r.t. channel configuration
- “pre” and “post” tracks to process engine channels before/after dispatching them to tracks
- Audio frontends pause/restart
- Switch from liblo to oscpack for OSC
- Option to set target OSC IP
- Channel specification in send&return internal plugins
- Extended parameter notifications, now multiple controllers can be updated easily at the same time
- LV2 parameter output support
- Command-line switches to disable OSC and gRPC
- Use vcpkg to manage most of third-party dependencies
- Refactored CMake configuration, now using SUSHI_ for options prefix
- Ableton Link updated to v3.0.5
- TWINE updated to v0.3.2
- VST3 SDK updated to v3.7.6
- Workaround for delayed ALSA MIDI event output
- Crash in MIDI dispatcher when deleting track connections
- Various JSON parsing fixes
- Memory leak in VST3 wrapper
- Issue with setting different samplerate from JSON and audio frontend
- Slow response to large numbers of VST3 parameter changes
- Peakmeter formatted level parameter scaling
- All build options renamed to SUSHI_XXX_YYY from XXX_YYY
- Vcpgk initalization step required at first build. See README.md
- Track channel config has been simplified. The JSON “mode” member has been replaced with an integer “channels” member. To create a multibus track, an additional member “multibus” must be set to true and the number of buses specified with the “buses” member.
- Tracks now only report the number of channels (and buses in the multibus case) and input and output channels and busses are assumed to be the same.
- All instances of “busses” in JSON configs and gRPC API have been corrected to “buses”