EBeast UI in the upper left vs. the original Beast-Gtk+ UI in the lower right
EBeast UI in the upper left vs. the original Beast-Gtk+ UI in the lower right

Last Tuesday Beast 0.15.0 was released. This is most probably the last release that supports the Gtk+ Beast UI. We have most of the bits and pieces together to move towards the new EBeast UI and a new synthesis core in the upcoming months and will get rid of a lot of legacy code along the way.

For a bit of background, we started the migration to C++ some 10+ years ago, but really moving the code away from a GObject and GParamSpec type system and a GValue based IPC system proved to take much longer than originally anticipated. In addition, the Beast synthesis facilities (many of which were introduced ca 20 years ago) are far from state of the art by modern standards. In particular the way synthesis modules have to be manually connected and how basic synthesis devices still have to be created from scratch with Mono voice modules feels very inefficient.

And so, we have spent the last few months/year on laying the foundations for:

  1. Rewriting the UI in HTML/CSS + JavaScript, since Gtk+, GnomeCanvas and Rapicorn (including tooling and writing UIs in C/C++) turned out too complicated and much too slow to work with for a plethora of reasons.

  2. Re-modeling the synthesis core and modules, based on tracks with stereo device chains and supporting full automation at sample granularity for all module inputs and settings.

The UI migration (A) really needed a lot of leg work to integrate Vue-2 with the Bse classes, properties and notifications. The Web engine was initially based on Electron 1.8 and then 2.0, in combination with the excellent v8pp bindings to have the V8 JavaScript interface with the Bse C++ API in the same process.

But due to major stability problems with Electron versions >= 3, the JavaScript ↔ C++ integration was moved out of process, using Websockets and Jsonipc — a JSON communication layer for JavaScript to interface to C++ in a standalone header. Even though it was created for Beast, the header file just depends on the STL and is generic enough to be useful for any C++ API. Using C++17 features and following the elegant design of v8pp, this could be accomplished in under one month. It moved the Bse functionality into a separate process BeastSoundEngine and did away with all stability problems we had while linking Bse into Electron. As an additional bonus, with a bit of extra care, the UI can now also be run by Firefox 68, which hopefully might work as a separate UI client one day - once (or if) Servo Desktop Web Apps are implemented.

The changes to the synthesis core (B) are in the early stages, but important ground work has already been integrated, like the move of the .bse file format to a new container format, and a lean layer to serialize the synthesis structures to XML. Stefan has several new synthesis module implementations up his sleeves, to be integrated once a modernized synthesis API is in place, that also supports full automation.

Post comment via email