I'm porting the web UI from Vue-2 to -3. Turns out to be more involved than I originally anticipated.

I kept getting an odd exception during my tests. It looks like Vue-3.0.0 can become confused when state watchers (created via Vue.$watch) are unregistered during a later stage of a component lifecycle - trying to remove item from `null`.

I fail to see the error in my code at least (which works fine in Vue-2) and suspect it's a genuine Vue bug, filed here:

github.com/vuejs/vue-next/issu

The standard CSS cursors don't really look suitable to convey insert + erase for piano roll notes.

Here is a first draft at creating cursors myself for editing notes in the piano roll editor, hotspots marked red.

Fiddlingโ€ฆ

I'm working on a new knob for , with bidirectional and unidirectional modes.

The updates may only use "transform:rotate(angle)" to utilize acceleration during automation.

Sadly, Chrome cannot compose *inside* and SVG, so I have some nasty splitting and layering of the elements going on...

I've written down the details of compatibly selecting modern instruction set extensions for the builds in a blog article.
The crux is avoiding extensions that are Intel only or AMD only.

testbit.eu/2020/intersecting-i

Web packaging technology is torture.

The last week, I've been fighting webpack, parcel, , babel and bili, just because vue stopped supporting and I had to figure what to use as a replacement in .
^^^ 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...

Today, I've implemented per connection cleanup of remote std::shared_ptr references in 's layer.

What we *really* need is per Javascript object cleanup of remote references though, but that requires FinalizationGroup support in Javascript:
github.com/tc39/proposal-weakr

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 0.15.0 was released.

This is most probably the last release that supports the + 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...

testbit.eu/2019/rewriting-beas

Beast version 0.15.0 is released.

is an LGPLv2+ music synthesizer and composer (), for .
This release supports Jack as PCM driver and the experimental Ebeast frontened got many style updates, play position pointers and supports the Space key.

Full news:
beast.testbit.org/#news

So I've been working on "upgrading" the Font Awesome package used by the new UI from 4.7.0 to 5.9.0.

Just โ€” in the end I found that the icons look way more crispy and professional in the 4.7.0 version.

Is it just me, or did anyone else experience this with ?

Beast version 0.14.0 is released.

is an LGPLv2+ music synthesizer and composer (), for , including a , real-time and support for Plugins.

The full release announcement is out now:

beast.testbit.org/#news
mail.gnome.org/archives/beast/

I am working on new UI controls (numbers, switches, text, etc) for ( based).

Sometimes it'd be nice to have a designer on the project who is familiar with software to bounce ideas back and forth with.

Courtesy of Stefan Westerfeld (who yet needs to create a Mastodon account), we now have fluidsynth2 support in master. And that means .sf3 ( + ) support.

The 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 (and ) and syntax highlighting was introduced. It is rendered to and and the was adjusted to closely match the Latex based PDF looks.

beast.testbit.org/#news

In
"Walking in my (Electron) shoes"
Gergely Nagy writes about having to deal with hate (!!) received from people for developing on .

Since I started moving 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.

asylum.madhouse-project.org/bl

Have been chasing a build bug on 28 for several days now.

Turns out it's actually a 8 regression, the one thing I usually expect to be least likely:

gcc.gnu.org/bugzilla/show_bug.

After a good sleep, the blog post about the new release is out as well:

testbit.eu/2018/beast-0-12-0-b

Waiting for the regression tickets to come in - or not ;-)

Just uploaded a new release of the , the first version that ships a pre-alpha Electronjs based user interface:

mail.gnome.org/archives/beast/

The other week I started writing what is essentially boost::serialization for , 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 tree, since we need this for future evolution of Beast's BSE file format.)

Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!