I'm working on a new knob for #Beast, with bidirectional and unidirectional modes.
Sadly, Chrome cannot compose *inside* and SVG, so I have some nasty splitting and layering of the #SVG elements going on...
Web packaging technology is torture.
The last week, I've been fighting webpack, parcel, #rollup, babel and bili, just because vue stopped supporting #browserify and I had to figure what to use as a replacement in #beast.
^^^ If that sentence sounds like it has too many web tech buzzwords, that's *exactly* the problem.
And it's only a fraction of packages I had to deal with...
Most packages have documentation, but only provide tiny puzzles of a much bigger picture that is revealed nowhere...
That's still unfinished though, why do I always need bleeding edge features?
Time for bed I guess, maybe the edge looks less bleeding tomorrow... ;-)
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...
Beast version 0.15.0 is released.
#Beast is an LGPLv2+ music synthesizer and composer (#DAW), for #Linux.
This release supports Jack as PCM driver and the experimental Ebeast frontened got many style updates, play position pointers and supports the Space key.
Beast version 0.14.0 is released.
The full release announcement is out now:
The #Beast source code is currently being rewritten in various places (CI, IPC, Build system, etc)
During the process, the various pieces of Beast documentation were converted to Markdown, structured and merged into a single cohesive document. Formulas can now facilitate #Latex (and #Mathjax) and syntax highlighting was introduced. It is rendered to #HTML and #PDF and the #CSS was adjusted to closely match the Latex based PDF looks.
"Walking in my (Electron) shoes"
Gergely Nagy writes about having to deal with hate (!!) received from people for developing on #Electron.
Since I started moving #Beast to Electron, I've also had several interesting discussions (but not
"hateful" encounters) with people claiming that it must be slow or resource wasteful compared to native toolkits, both of which aren't really true in Beast's development context. Development itself is vastly superior though.
Turns out it's actually a #gcc 8 regression, the one thing I usually expect to be least likely:
The other week I started writing what is essentially boost::serialization for #XML, i.e. C++ member serialization + field names to allow text based formats. The serialization format also needs to support arbitrary object graphs with interconnections.
I've not found a similar FLOSS library that solves this, and started wondering if the code makes sense as a general purpose library. (So far it lives inside my #Beast tree, since we need this for future evolution of Beast's BSE file format.) #cxx
DSP + UI developer on the Beast DAW, Free Software author + advocate, contributor to ALSA/GNOME/procps/LibreOffice/etc.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!