Reanimate website sources.

Ben Niemann 1 year ago
parent 9181ae4118
commit b6e8ffe564

.gitignore vendored

@ -8,3 +8,6 @@

@ -0,0 +1,17 @@
set -e
ROOT="$(realpath "$(dirname "$0")"/..)"
if [ ! -d website/.venv ]; then
/usr/bin/python3 -m venv "${ROOT}/website/.venv"
touch "${ROOT}/website/.venv/.nobackup"
"${ROOT}/website/.venv/bin/python" -m pip install -U pip setuptools wheel
"${ROOT}/website/.venv/bin/python" -m pip install -e ~/projects/odasite
export DIFF=$(which meld)
"${ROOT}/website/.venv/bin/odasite" -c website/ "$@"

@ -25,9 +25,8 @@ let
in nixpkgs.mkShell {
packages = [
inputsFrom = [ noisicaa ];

@ -0,0 +1,19 @@
This is the source code for the website.
Note that it's using a static site generator called `odasite`, which is currently not publically
available, so the following instructions only work for myself.
# Editing
bin/odasite serve
View website at http://localhost:8000/
# Upload
bin/odasite remote-diff # Review changes
bin/odasite upload

@ -0,0 +1,25 @@
Title: Sins of my Youth
Date: 2015-12-03
I mentioned the [Deluxe Music Construction
Set]( before. I used that mostly to
transcribe sheet music, which I found in the public library. Some classical pieces,
e.g. - because that movie is awesome, and if I remember correctly some
of the older Genesis songs. I can't remember if I actually tried to write my own music with it -
whatever files I saved back then are gone forever.
But I also played around with "trackers" - I think it was mostly
[NoiseTracker]( and
[OctaMED]( And strangely enough, even after ~25 years I still
have those files sitting on my harddisk. And there's even software that can play them back or
convert them to slightly more modern formats.
Just for the giggles, I uploaded some of those to
<iframe frameborder="no" height="450" width="50%" scrolling="no" src=";auto_play=false&amp;hide_related=false&amp;show_comments=true&amp;show_user=true&amp;show_reposts=false&amp;visual=true" width="100%"></iframe>
I can't claim that my artistic skills have changed, let alone improved, in the meantime.
But I'm probably a better coder now.

@ -0,0 +1,7 @@
Title: Initial commit on GitHub
Date: 2015-11-29
I've been working on this project for a while already, but only now made it public on GitHub. It's
not yet in a state where it's usable though - that'll still take a while.
And I guess I should also describe what this is about at some point...

@ -0,0 +1,106 @@
Title: Introducing noisicaä - A simple music editor
Date: 2015-11-29
I don't know much about music, but it's a topic that interests me.
I don't play any instruments and I'm too old or too lazy to learn one. Probably both.
But I'm one of those computer persons, so I would naturally use a computer to make music - or at
least attempt to.
So I looked around what software is out there, but the stuff I found didn't get me terribly
excited. Now I have to add that I'm using Linux (Kubuntu on my desktop to be more specific) and
while I also have Windows on my machine, I wouldn't want to use it - except as a bootloader for
Steam. I also didn't look at commercial software, just what's out there in the open source
world. That limits the selection. And the stuff that actually exists in that small subsection of the
market is either too simple or overwhelmed me a ton of options and possibilities that I don't know
how to use, because I don't actually know what that stuff means.
On the other hand I still remember playing around with the [Deluxe Music Construction
Set]( on my Amiga back in the days. And
that level of complexity (or the lack thereof) feels like exactly the thing that would be
appropriate for me today.
So because I couldn't find any existing software that I liked, I started writing my own. Also
writing code is fun, so I don't really need a reason.
I'm also using this opportunity to play with some fancy tools, which I haven't used yet: Python3
(it's about time), Cython (sounded like a cool toy, but I never had a reason to use it before) and
Qt5 (I've been using wx for UIs in the past, but I like Qt way more now).
I'm also giving git another try. Well, we'll see. That has been quite a lackluster experience in the
### What's different about noisicaä?
noisicaä uses classical musical notation. Putting notes onto staves, clefs, measures. etc. Most
"modern" software seems to focus on a sequencer style interface. My little bit of knowledge about
music is stuck in the time when I had music in school, and continuing from that point seems to be
easiest for me. Perhaps later I'll figure out that the piano roll UI of sequencers is indeed more
powerful than the system that been used by Bach and Mozart back in the days. But the software can
make that transition together with me, as I acquire more skills.
Another thing that seems popular, especially in the realm of commercial software (which I can only
tell from seeing random screenshots on random websites, since I never used any of these), is that
the UI simulates existing hardware. That might be nice for people with existing experience in making
music using real instruments and studio hardware. But for me that's just another obstacle, because
in addition to learning about the musical domain itself, I would also have to deal with a user
interface that doesn't follow known guidelines. At least known to someone who never set foot in a
music studio, but worked with computer for the past 25 years.
So noisicaä's UI rather follows established schemes that you would also find in IDE, office suites,
and the likes.
### Features
Not a lot yet. This is still pre-alpha state software.
There's some basic editing and you can play it back. The instruments are currently rendered using
[FluidSynth](, i.e. it uses soundfonts. I have vague plans to
also support plain .wav files as samples, or use synthesizers to create
instruments. [Csound]( seems like the kind of arcane but powerful system
that I could like a lot.
Of course the music should eventually be rendered as .flac, .ogg, etc. files, but that doesn't exist
There should be some support for filters and general mixing/production features, so I get a little
bit more than the typical MIDI
sounds. [LADSPA]([LV2]( plugins and again
Csound seem to be the right tools for that.
I'll also do something with MIDI input. There's a little MIDI controller here on my desk, that wants
to be entertained. But probably not real-time recording, because I could play anything in real-time
that's worth recording.
And in the further future I'm also thinking about some hybrid system which mixes composed tracks
with recorded tracks - where the source of the recording will probably be my wife playing the guitar
or bass.
And who knows what. That'll depend a lot on where my learning curve takes me. I will use this
project to implement those things that I learn about music, so I can apply them.
### What, music software in Python?
That's right. People seem to make a big fuzz about latency, real-time support in the kernel and that
kind of stuff. They probably know better than I, but I'll ignore that advice anyway. Most of the
coding is around the UI, persistence, etc. and not involved in the playback at all. And despite not
having spent a lot of time into optimizing anything, I haven't observed any buffer underruns during
playback yet. Perhaps using a totally overpowered desktop is just good enough (though it's already a
few years since that machine was "high end").
Also I don't see noisicaä as a tool to be used on stage for live performances. So occasional
glitches do not worry me a lot.
And then there's [Cython](, which I started using mostly for interacting with C
libraries. I already use it for some of the bit crunching parts - not because those already needed
optimization, but just because I wanted to play with it a bit more (aka. premature optimization).
### So... you want to make music?
That's the weak spot of this whole enterprise. I seriously doubt that I have the creativity and
artistic skills to produce something that could actually be called music. Or warrant all the effort
I'm now putting into this. Even after I learned all the theory that there is to learn and created
the greatest software that any artist could dream of.
Bah, who cares...

@ -0,0 +1,6 @@
Title: Photos, or it didn't happen!
Date: 2015-12-03
Just to prove that this thing actually exists:

@ -0,0 +1,38 @@
Title: LV2 confusion with internal presets
Date: 2018-03-04
I managed to get the [Helm]( synth working as an LV2 in noisicaä, including
UI. Which is great, because that's a very nice synth.
But I ran into an issue, which caused me some head scratching, because I thought that I was doing
something wrong. As it turned out, this is really a problem with (at least) LV2 and Helm's feature
to load presets from within its own UI.
Helm's internal state is determined by the values of the 100+ control input ports, plus some
additional state that isn't captured by those ports (e.g. which controls are modulated by an LFO).
Now when you load a preset, Helm sets all of its control to specific values, but it has no way to
tell the host about those values. Which means the host is still feeding the previous values into all
control input ports. Helm seems to have some logic to ignore those values from the host, until you
actually change them from outside of Helm (e.g. via automation or the generic UI). If you change
some control manually in Helm's UI, then the values are posted from the UI to the host, so it can
update the value that it feeds into the respective control port.
But if you now close the project and open it again, Helm's state gets all messed up, because for
most control the host never learned about the right value from the preset that you selected, and
Helm gets initialized with effectively random values. Things get even more confusing, because the
control values are also stored in Helm's '[internal
state](' blob and depending on the order in which control
ports and internal state are initialized you get different results.
Turns out that [Ardour]( has the same issue, so I'm not alone with it. I don't
know, if e.g. the VST API solves this issue, or if it was generally a bad idea to have presets,
which change the values of control ports - and manage them within the plugin itself. If the presets
would be handled in the UI, then LV2 has the API to set the control ports... or is it just a bug in
Helm, that this API isn't used when switching presets?
So the lesson is to not touch the preset browser in Helm, but instead use the preset menu from the
host - which has the same list of presets, and knows how to set the control port correctly when
loading a preset.
But noisicaä doesn't know about presets yet...

@ -0,0 +1,27 @@
Title: The nature of mixing
Date: 2018-07-04
Just a little thought in between, while I'm writing a longer post...
The concept of mixing audio, applying filters, processors and whatnot to perfect and polish the
sound is actually quite artificial, at least to the extend that it's being done these days.
If you think about how music was performed for most of humanities existence, all you had were the
"raw" sounds of the performers. There were some limited ways to tweaks those, like "hey you, don't
hit those drums so hard" or "you, come to the front, so we can hear you better", but that's about
And while people for sure noticed the difference that the environment had on the experience, if they
didn't have a cathedral at hand that would give the chorus that impressive volume, they would still
enjoy the performance in a normal room.
The ability to micromanage sounds, in the way we can do it now in the studio, feels like a
qualitative step beyond what we used to be able to do in the past. Like going from some salt and the
herbs that grow in your backyard for spicing your food, to glutamat and a whole catalog of
E-something chemicals used for industrialized food production.
Yes, those tools that we have today are great, and it's even greater that they're now available to
anyone with a computer. But be careful and conscious about how you apply them.
At least I, when I make a pizza myself at home, don't want it to taste like a frozen pizza out of
some factory.

@ -0,0 +1,62 @@
Title: Development update (January 10)
Date: 2019-01-10
Development made had a small hiatus in second half of 2018, but in
December - thanks to a lot of spare time - I picked coding up again.
The biggest and most visible change was that I completely rethought
the general idea behind noisicaä. In the beginning I started out with
something that should resemble a piece of paper with staves on it,
that lets you easily create, edit and play music, and I only
envisioned basic audio processing features. Over time that turned into
something much more like the typical DAW with tracks and plugins and
all that stuff. But I wasn't very happy about the way DAWs typically
manage the audio processing. In my mind manipulating the actual
processing graph feels like the most intuitive way, something like
[Pure Data]( or a modular synth. Which also
happens to be the way the engine works internally. I didn't quite know
how to make this properly accessible, so I just had something basic in
At some point I came across a [video
demo]( for
[BespokeSynth]( and I really
liked the general approach of that UI. Eventually I started thinking
more about what noisicaä should actually be. The primary use case has
always been musical composition, and that doesn't change. But most
apps have some kind of metaphor to the real world that they're built
upon (e.g. sheet music for [MuseScore](,
recording studio for [Ardour](, etc.). And I
simply decided that noisicaä's foundational idea should be the modular
So made did a major refactoring, putting the processing graph onto the
center stage, both in terms of internal code structure, as well as on
the UI. There are still tracks, and they are prominently featured on
the UI, because time and temporal editing remains to be a central
ingredient. But e.g. now you add a 'Score Track' node to the
processing graph, which will also add an editable track, instead of
the other way around.
Another major change during the past weeks was that I finally got
around to purge all Python from the critical path in the audio
thread. This is now all C++ and hopefully realtime safe. Now playback
even at smaller block sizes is much more reliable.
Finally on the more organizational side, I adopted a scheme of doing
"sprints". Well... I know that there is some development methodology,
which uses the term "sprint", but I don't even know which one that is,
what it exactly means by that word, nor do I intend to adopt any
methodology or become serious about project management or anything
evil like that. But it seems to work quite well to structure that
gigantic pile of ideas, which I want to implement, into reasonably
sized chunks, and then spend a week or two tick off all the boxes for
one of those chunks. And I just call those chunks "sprints".
And maybe, just maybe... if every other week or so, when I merged
all the changes for a completed sprint into the master branch, and
have that nice feeling of accomplishment... maybe that also makes me
want to write a post with a short update of what I did. Otherwise this
blogging thing simply doesn't seem to work for me, as you can tell
from the frequency of postings.

@ -0,0 +1,28 @@
Title: Development update (January 14)
Date: 2019-01-14
I just finished a "MIDI in" sprint and [merged it into the master
Oops, I just noticed that I forgot to remove the commit messages from the branch. I usually to a
`git merge --squash [branch]`, so there's just one big commit to the master branch, instead of
dozens of small ones, and also write a commit message summarizing all the changes. git helpfully
prepopulates the commit message with all the individual commit messages from the branch, which I
then just remove. Except for today...
### What's new
There is now a "MIDI source" node, which can be used to feed MIDI events from any ALSA device, e.g. you USB keyboard, into the graph.
There used to be some similar functionality written in Python, but that lived on the UI side and
MIDI events were fed to the backend via RPCs. And that implementation gradually fell apart, as I was
refactoring things over the past month. So the only place where it was used (the onscreen keyboard
in the instrument library, which could be connected to a real MIDI keyboard) didn't even work
The new implementation is pure C++ and MIDI events are collected directly in the audio
thread. Of course except for that onscreen keyboard, which still has to send it's MIDI events via
RPC to the engine. But that's now done using the same mechanism for communicating with node
processors, which is also used for other things.

@ -0,0 +1,26 @@
Title: Modular DAWs
Date: 2019-01-25
I recently came across those two announcements:
* [Loomer Architect: A modular MIDI
toolkit]( (via
* [Bitwig Studio is about to deliver on a fully modular core in a
DAW]( (via
I only read those articles and looked at the pretty pictures, but haven't tried out any of
those. But judging from that superficial glance, both these projects seem to move into the same
direction as noisicaä. The Bitwig article also lists some more software with a similar approach. So
it appears that my idea for a modular DAW isn't that unique, possibly rather old, and perhaps some
recent trend thing (the last two aren't necessarily a contradiction).
I'm trying to pay not too much attention to other audio software, which includes *not* trying that
stuff out myself. This is partly to keep myself in blissfully ignorant that what I'm doing has
already been done before (and probably better), i.e. a waste of time. But also to keep a fresh
perspective and possibly create something new, instead of just cloning what already exist - assuming
that I actually have any new ideas, which is doubtful. And finally, if I'd get too much inspiration
from other projects, I would just end up with an unmanageable pile of ideas of all those great
things I should add to noisicaä, and would never get done. But I do keep a list of bookmarks of
stuff that I find along the way, including related or similar software projects.

@ -0,0 +1,42 @@
Title: Development update (January 27)
Date: 2019-01-27
Just [merged the
branch]( for a
"command cleanup" sprint. This was mostly an internal cleanup with just a few user visible changes.
### What's new
Now some sequences of commands are merged into a single command.
Every time you make a change to the project, a command is issues for it and (in broad terms) this
command is appened to the "undo list". Turning a dial could produce dozens if not hundreds of
separate commands, and an 'undo' would undo each of those one at a time.
Now new commands might get merged into the previous command, so a sequence of many control value
changes is collapsed into a single change. And 'undo' will undo all those changes in one step.
It is also possible again to set the pitch for the note events produced by a beat track. That got
lost in some previous refactoring.
### Internal changes
The major part of the sprint was to cleanup the commands, which are internally used by the UI to
modify the opened project. Initially I used very fine grained commands, e.g. a dedicated command
`SetClef` to change the clef of a measure. The whole thing grew quite organically and I never
developed a consistend scheme.
Now I changed that to a basic [CRUD
scheme](,_read,_update_and_delete), i.e. most commands are
called `CreateFoo`, `UpdateFoo`, `DeleteFoo` (ok, it's really `CUD`, but whatever). And instead of
separate commands to change the various properties of an object (like the `SetClef` mentioned
above), there is now just a single `UpdateFoo` command, and which property should be changed is
determined by the presence of specific fields in that command (which are just [protocol buffer
While doing those changes I also got tired of typing names like `PipelineGraphNode`. Given the
central role, which the graph and the nodes therein should now play, I renamed those to the much
more compact `Node`, `NodeConnection`, etc.
And some minor cleanups: simplify the API of the `Command` class, add factory functions for all
command protos (for some more type safety).

@ -0,0 +1,29 @@
Title: Development update (March 3)
Date: 2019-03-03
Just [merged the
branch]( for the
"Proto IPC" sprint. This was again mostly an internal cleanup with no significant user visible
### Internal changes
The internal communication between processes now uses (almost exclusively) protocol buffers instead
of pickled Python objects. The IPC code has also been optimized a bit to make it a faster.
### WTF am I doing here?
So I started out with the ambition to make music. Instead of, you know, pick up some existing
software and just go ahead, I decided to write my own. As if that would be more efficient in any way
(but it's fun and enjoyable for me).
And now, instead of, you know, adding musical features to it, I spend my time working on completely
unrelated infrastructure stuff, for which there is probably some existing library that does a better
job than me (but it's fun and enjoyable for me).
I guess you can call that "productive procrastination", though [existing
of that term seem to be see it in a more favorable view that I would do. So I would like to get more
focused on what I really want and at least work more on the musical features of noisicaä. The
ambition to eventually make music with it shouldn't totally disappear. But I won't be able to
completely suppress my urge to give the code base some polish from time to time...

@ -0,0 +1,33 @@
Title: Development update (March 24)
Date: 2019-03-24
I got a little bit distracted by reading too much about Emacs and tweaking my config for it, so
noisicaä had a little downtime of about three weeks. But to get things rolling about, I had a little
"Expose Ports" sprint, which I just
[merged]( into
### What's new
Control ports, which previously could only be set interactively to a fixed value, can now be
"exposed" as normal ports, so you can connect them to other nodes. Basically what other DAWs call
The UI is still suboptimal - it's just a nameless checkbox next to the dial. This also only works
for the generic node UI so far. Other built-in nodes with a custom UI should also get that feature,
but I'll have to think about the UI design. Perhaps make this available via a popup menu on all
Also a-rate control ports, can now be used like k-rate control ports, i.e. either set the value via
a UI dial or expose and connect them to other nodes.
### Bug fixes
* Fixed a crash when removing node with connections.
* Fixed a crash when removing some LV2 plugin nodes, where there is some issue with the [State
extension]( The issue still exists (a traceback is dumped to the
log and state collection stops), but doesn't cause a crash anymore.
### Internal changes
* Dump audio engine opcodes to the log (via the "Dev" menu).

@ -0,0 +1,28 @@
Title: Development update (April 6)
Date: 2019-04-06
This [commit](
adds the capability to have nodes with dynamic ports, i.e. the list and types of ports are not
static anymore, but can change during the lifetime of the node. For now this is only used by one
builtin node type, but I plan to make more use of that feature in the future. E.g. to have a single
"VCA" node with a flexible number of channels, instead of needing a number of separate "VCA (mono)",
"VCA (stereo)" nodes.
### What's new
The Custom CSound node now has a dynamic port list. Ports can be added, removed and modified.
### Internal changes
* The NodeDescription of a node can be generated dynamically. Changes are propagated to the audio
engine and for some changes, e.g. port type or direction changes, the underlying processor
instance gets reinitialized (which does cause a brief audio glitch, if the processor is hooked up
and producing sound).
* Added node parameters, which are persistent in the audio engine graph, but not part of the
project. Used for setting the CSound orchestra and score of the Custom CSound node. Processors
already had the concept of parameters, which has been assimilated into the more generic node
* A new ObjectListEditor class, which provides a table widget for editing lists of
objects. Currently only used for the port list editor of the Custom CSound node.

@ -0,0 +1,62 @@
Title: Development update (April 25)
Date: 2019-04-25
The latest
primarily adds a handful of new builtin nodes.
This "MIDI CC to CV" node actually poses an interesting problem. It is inherent to MIDI controllers
that only changes of the controller positions are communicated, which implies that on startup you
don't know what the current position of the controller is until the first change event comes in.
You could use the control values coming from the MIDI CC to CV node to control some sounds and tweak
the controllers to get the sound that you want, but when you then close the project and open it
again on the next day, the control values are reset back to zero. If you're lucky, then the MIDI
controller is still plugged in and the knobs are still in yesterdays position, so you could wiggle
every knob just a little bit to get the system back to almost the same state as it was.
noisicaä should arguably store the most recent value of each controller, but how should that exactly
work? If every value change is applied as a project mutation, then that implies that these can be
undone, which is kinda weird (how should the software undo a physical movement of some piece of
hardware?), but ok. But this node doesn't have to be connected to some actual hardware input. It
could just as well get its input from some node that generates CC events, e.g. a recorded MIDI
stream or some generative music thing. Then playing back the project would modify the project and
that really doesn't make sense.
My best answer to this problem is that this node simply should not be used to connect hardware
controllers to a project. It should only be used to converted recorded or generated MIDI CCs into
control values, and the current behavior will stay, i.e. the current values is transient and not
persisted. And at some future time it should be possible to link control dials to a hardware
controller - not via a port connection, but rather as an additional UI option. Those value changes
would then be recorded as project mutations, so they become persistent, i.e. the hardware controller
would just be used instead of the mouse, but the effect would be the same.
Another thing that became apparent during this sprint is that the amount of boilerplate code to add
new nodes is still way to big. While I could have easily gone on and add more nodes - especially
ones that can be fully implemented in Faust are pretty easy to do now, i.e. pure DSPs, which don't
interact with MIDI events or need more than the most basic UI. But the urge to do yet another huge
refactoring kept growing. So now I'm at a point where I say to myself: "Look, I added some new
features, can I now [do something fun again](03-03-development-update)?" And I can't really say "no"
to myself.
### What's new
The following new node types have been added:
* Oscillator: a simple oscillator with sine, sawtooth and square waveforms.
* Noise: white/pink noise generator.
* VCA, with optional smoothing of the control signal.
* Step Sequencer, with up to 128 steps and 100 channels, where each channel can produce either a
control value, a gate signal or a short trigger signal.
* MIDI CC to CV, converting MIDI controller change events into a control signal.
The insert node dialog gained some icons and displays information about the nodes, to give you some
more hints about what you're inserting beyond the name itself.
### Internal changes
* A new ProcessorFaust class for nodes based on [faust]( For now
only supports statically compiled code, i.e. users cannot (yet) edit and run arbitrary faust code,
like it is possible with Csound.
* Ports can be specified with a list of "label -> value" mappings, and the UI turns that into a
combobox instead of a dial.

@ -0,0 +1,239 @@
Title: The great "Model Merge" refactoring
Date: 2019-04-28
As I mentioned in the [previous post](04-25-development-update) I plan to do yet another great
refactoring. But before I jump head first into this adventure, rip everything apart and rewrite
something like 60% of the code base, I want to take a step back and describe my plan here. Looking
at the [AWStats]( for this website, I'm well aware that I'm just talking to
a void, but the point is really for myself to reflect on this, think it through one more time and
make sure I'm not overlooking something, which would turn this plan into a nightmare, after I
already spent a lot of time on it.
But before I start explaining my plan, I should first explain the current architecture and what the
problems and benefits of it are.
### The current architecture
The three main components of noisicaä are the UI, the project and the audio engine. The "project" is
the part, which owns the internal data structures that describe the project (the "model") and is
responsible for all changes to it (i.e. the "business logic") as well as persisting those changes to
disk. Those three components each run in different UNIX processes and communicate with a homegrown
IPC system with each other. Above those three processes is a main process, which is the one the user
creates when launching noisicaä, and it only does a little more than starting the other processes as
needed. There are also some other processes, and there is actually one project process for each
opened project, but that doesn't matter in this context.
The "model" is quite similar to e.g. the [HTML
DOM]( - a tree structure of objects, that each
have a certain set of attributes. The authoritative model lives in the project process, but the UI
has a read-only copy, which it uses to build the interface for the project. For every user action
(that modifies the model) the UI sends a command to the project process, which executes it by
performing some sequence of changes to the model. Those changes are recorded as a list of
"mutations", which are persisted on disk and sent to the UI process, where they are applied to the
read-only model, which in turn triggers the necessary interface changes. Changes to the model in the
project process can also trigger updates to the state of the audio engine, but that part of the
system is out of scope of this discussion.
That setup seems to be quite convoluted and over engineered and I cannot really disagree. But I did
have reasons, when I designed this architecture:
#### Failure domains
Software has bugs, applications will crash, but data loss or corruption in unacceptable.
Specifically the UI feels problematic, partly because I haven't really figured out how to write good
unittests for UIs, so my level of trust in my own code isn't that high. Also the UI involves a lot
of native code, i.e. the Qt framework, so a bug often results in a segfault and not in a Python
exception, which I could handle more gracefully.
The code of the project process on the other hand is much simpler, written in pure Python and a lot
easier to test.
By putting the UI and the model in separate processes, a crash of the former cannot corrupt the latter.
#### Clean interfaces
In order to support undo/redo any change to the model must be wrapped in a command. Those commands
can then be reverted or replayed as needed. That pattern seems to be fairly common, e.g. Qt also
[offers it](, though I'm not using that implementation for
Any change of the model outside of a command would lead to corruption, but only in combination of an
undo or redo, so this is hard to detect. And I know I'm lazy, so for rapid prototyping it can be
very tempting to directly change the model from the UI and then "clean it up later" - but actually
forgetting small bits here and there, which would be a source of subtle bugs. This architecture
forces me to go through that "command" interface, because the UI simply has no other way to change
the model.
### Problems of the current architecture
This architecture requires two views of the model, one in the project process and one in the UI
process, which are synchronized by sending mutations from the project process to the UI process over
IPCs. The model in the UI is limited to read-only access, whereas the model in the project process
has all the methods to implement the business logic. This results in a quite convoluted "three
dimensional" class hierarchy. I.e. every class exists three times, one abstract version, which
describes the properties of the class, one read-only implementation and one mutable
implementation. Combined with the "normal" class hierarchy (e.g. a `Track` is a subclass of `Node`,
which is a subclass of the fundamental `ObjectBase`), this results in a complex inheritance mesh,
which is pretty hard to reason about. For example there was a recent bug, which caused me a lot of
head scratching, until I noticed that I forgot one link in the inheritance mesh, but the observed
bug provided no indication that this could have been the cause.
That setup also requires a lot of boilerplate code and the code is spread across many places, which
makes it really annoying to add new classes. This point is what really caused me to questing the
current architecture and look for alternatives.
### The plan
My plan is to not create a new process to host the business logic but rather have a single model
running in the UI process (for each opened project).
But I'm paranoid about data loss or corruption, so I want to spawn a separate process per opened
project, which is responsible for writing the mutations to disk. So if the UI crashes, that writer
can flush out all pending data and the shut down gracefully.
Instead of sending a command from the UI to the project process, the command could be directly
applied to the model in the same process. This will change the order in which updates will
happen. In the old architecture, the changes will be applied completely in the project process,
before they are sent back to the UI, which applies it to its copy of the model and triggers all
required UI updates. If there is a bug in the UI, which causes it to crash while it processes the
mutation, then the command has already been completely applied and persisted in the project
process. Now the UI updates will be triggered while the command modifies the model, and if that
triggers a crash, then the command execution does not complete and nothing gets persisted. That's
probably better as it prevents the model to get into a state that would cause the UI to get into a
crash loop.
Having just a single model would remove the need for the complex class hierarchy. I could merge
those three incarnations of each class into a single class, so semantically related code moves
closer together and a lot of duplication and boilerplate should disappear. But that means that the
UI has at least technically the ability to directly change the model outside of a command execution,
sidestepping the process, which is required for a working undo system. But there is already a system
in place to monitor all changes to the model (which is used to record the mutations during the
executing of a command), so I could just use that to trigger an assertion whenever such a forbidden
model change happens.
Once that first refactoring is done, I would also want to drop the concept of explicit `Command`
classes. All I need is the sequence of mutations that happen as a result of some user action. These
mutations are what is persisted to disk and they can be applied to the project in backward (for
"undo") of forward (for "redo") direction - that's how it already works today. For that it is
sufficient to mark a section of code as "this is a command" and there's not need to actually create
some `Command` instance and pass that around.
In pseudo code the current flow looks like this:
# In the UI, triggered by some widget change:
send_command('UpdateTrack',, name=widget.text())
# In the project process:
class UpdateTrack(Command):
def run(self):
track = self.get_object_by_id(self.track_id) =
where `send_command()` serialized the command, sends it over IPC to the process project, which would
create the `UpdateTrack` instance, and call its `run()` method while tracking all mutations to the
model ("set the 'name' property of the object '1234' to 'New name'"), and then persisting those
mutations to disk and sending them back to the UI.
Note that `send_command()` is a coroutine, so all those steps that it triggers happen asynchronously
without blocking the UI. Which has so far not caused problems, but in theory a fast user might be
able to trigger further actions, before the results from the previous command have been applied to
the UI, which could cause all kinds of weird behavior.
With the new architecture the same would look like this:
with project_mutations(): = widget.text()
Here the `project_mutations()` context manager would do the collection of mutations for persistence,
whereas there wouldn't be any additional action needed for "sending anything back to the UI",
because the changes are directly applied to the model that the UI already monitors.
And it should be possible that everything within that context manager is synchronous, so the user
cannot actually interact with the UI while those changes are applied (which usually should not be a
noticeable time).
### What I lose
#### Static API enforcement
In the old architecture the contract that the UI only has a read-only view of the model can be
statically checked with [mypy](, because the classes that the UI sees only
have read-only properties.
This would change, because now the UI sees the one implementation of model, with all the properties
and methods, which are also needed for changing it. The UI is still not allowed to use those
(outside of the explicit execution of a command), but violations of that contract can only be caught
at runtime.
#### Graceful UI crashes
Given the old architecture, the UI process could just restart after a crash and reconnect to the
(unaffected) project process. This could even go as far as not disrupting the audio playback at all,
i.e. the audio would just continue playing, if the UI goes down, and when the UI comes back up,
everything is as if nothing happened (of course the UI might enter a crash loop, if the cause of the
crash is deterministic). Note that this is not implemented, but it could well be done with the old
With the new architecture, the project state would be lost along the with UI, if the UI crashes, so
the project would have to be reopened as well. In theory the audio engine would still be unaffected
by such a restart, but reconnecting to it and syncing state would be much harder, if feasible at
all, so all audio engine state related to the project would have to be torn down and recreated when
the project is reopened.
So with a pessimistic outlook, where I assume that the software is unreliable and often crashing,
the old architecture would provide a better user experience. I guess I have to be more optimistic
and just make the code more reliable.
#### Remote UI
Another idea, which is also not implemented, is to allow the UI to connect over the network to a
project running on a different machine. E.g. I could imagine multiple people working on the same
piece of noise simultaneously, each one with their own workstation/laptop. That seems like it would
be fairly straight forward with the old architecture. 90% of that could be achieved by using TCP
sockets instead of UNIX domain sockets for the IPCs between the processes. But the remaining 10%
would still be tricky. Writing distributed systems is a very different pair of shoes, because you
have to be resilient against delays or network failures for every IPC. And for all kinds of file
access, you can't assume anymore that all processes see the same local filesystem.
So while this is a kind of nice idea, I'm not too sure if it's worth pursuing at all.
### What I win
#### Less code
The current architecture requires a lot of boilerplate code and the new architecture should remove a
lot of that. Less code is good.
The amount of code to implement the model should be reduced significantly, because I get rid of that
class triplication that I described above.
Also many commands are actually just changing a single property, and those could be implemented much
more efficiently. A common pattern is to have one UI widget which is connected to a property of one
object. Right now setting this connection up and synchronizing changes in both directions requires a
lot of fairly dumb code - very repetitive, but different enough to make it hard to have a generic
function taking care of it. The new architecture should help here, too.
This code reduction is really my main motivation for this refactoring, and I would be very
disappointed, if the final diff, when I merge it into master, does not have a net negative line
#### Performance
The communication between the UI and the project will not go through the IPC layer, so noisicaä
might become a bit snappier. Though I don't really see a performance issue as it is today, so this
is more of a theoretical improvement.
### Verdict
I don't foresee any issues, which could be showstoppers for this refactoring, and I do think the
gains are worth the losses.
I do have to admit that this write up didn't grant me any new insights. I already had a bunch of
unordered notes and my hope was that turning those into this more structured document would cause me
to see things, which I have missed before. But I'm either still missing something important or there
wasn't anything missing in the first place.

@ -0,0 +1,32 @@
Title: Development update (May 19)
Date: 2019-05-19
The great "Model Merge" refactoring, which I described in the [previous post](04-28-model-merge) has
Overall it was mostly painless and worked the way I planned. In the beginning it felt a bit like a
massacre as I was tearing down a lot of code, and the whole thing was in some messy intermediate
state, but quickly new patterns emerged and the conversion became mostly
mechanical. [mypy]( and [pylint]( were very helpful
tools during this adventure. I basically went from one file to the next, fixing all the issues that
they complained about and at the end, when all pieces fell into place and I had something executable
again, there were just very few bugs left - I think just one issue, which was detected by a unittest
and one or two issues I found through manual testing. The biggest advantage of those tools over
unittests alone is that they produce meaningful reports for a single file even if the code at large
isn't in a usable state. I had to refactor a lot of code in different places before I could even get
any passing unittests and without mypy/pylint I would have been flying blind for that time.
After I executed my plan, I had took another stab at the idea of auto-generating some of the
boilerplate code for model classes. I tried it once before, but abandoned it again, because it
turned out to be too complicated. But with the new, much simpler code structure after the
refactoring, it became much easier to do. That got rid of another batch of "boring" code and adding
new classes (e.g. for more builtin node types) should now be much less cumbersome than it was
According to [SLOCCount]( the total code base shrank by
approximately 3000 source lines of code or 6% (or almost 8% when just looking at the Python code),
which is quite considerable.
With this project out of the way (and out of my head), I should do some "shiny new features" sprint

@ -0,0 +1,71 @@
Title: Development update (June 13)
Date: 2019-06-13
Time for the [next
commit]( This
was mostly about streamlining the setup process for the application, but I also added some more new
stuff, which felt related. I could have added a lot more features around managing projects, but I
postponed those to another time.
### What's new
#### More responsive startup
When starting the application, the window now opens much earlier, showing a process bar while the
application is initializing. I decided against using the typical "splash window", because by
directly opening the main application window, I can already show the "open project" dialog and let
the user choose which project to open, before the application is fully initialized. This probably
cuts a few seconds from starting the application to the project being opened. Thanks to Python's
[asyncio]( package, which I've been using anyway,
this didn't require any significant changes, nor did I have to bother with background threads and
how to communicate with the UI, etc. Coroutines FTW!
#### New "open project" dialog
This "open project" dialog is now a custom widget in the main window (on any new project tab), and
not the standard file dialog. In terms of features and usability it probably needs some more
polishing, but it should be good enough for now.
#### Project debugger
And then there's an initial version of a "project debugger". It can only display the list of
mutations, and you can "truncate" the list, i.e. remove the latest mutations. This can be useful, if
some action got the project into some broken state, so it fails to open. Then you can try to repair
the project by removing the offending changes. Hopefully this won't be needed that often by future
end-users, but right now during development, this happens quite frequently. So far I have just
discarded whatever project I had opened, but at some point I should really start and try to make
something proper with noisicaä. Something I wouldn't just toss away because of some silly bug...
#### "New project" dialog
There's a silly gimmick in the dialog for entering the name of a new project. The project name is
pre-filled by a "random song title generator". It comes up with some funny names and who knows,
perhaps inspires some awesome noises. The rules for those names come from the [Time of Forbidden
Spells](, which just happened to be the most
promising candidate when I searched for ["song title generator" on
GitHub]( The titles are a
Metal-style, which might not be everyone's cup of tea, nor the most appropriate for noisicaä, which
is more suited for electronic music (at some future point), but I kinda like the results. "Vomit of
the Song" &#x1f918;
### Bug fixes
* I fixed a crash when you deleted a node, closed the project and the reopened it.
* When the project fails to open for whatever reason, a dialog just tells you about it and you get
back to the "open project" dialog - instead of completely crashing noisicaä. Again something that
hopefully doesn't happen often for end-users, but is quite frequent during development.
### Internal changes
I slightly changed the file structure for projects. Now each project has a single directory, and all
files are stored in that directory.
And the only significant change I had to make to get the startup process working smoothly was to
reorganize the instrument library. At least on my machine it contains a few thousand entries, and
initializing that list blocked the main thread for a second or so. I reorganized that code such that
the list is now built in smaller chunks. And as a side effect of that reorganization, that work in
only done once instead of every time an instrument library dialog is opened. In QT speak: there's
now a single InstrumentList object, which implements the
[QAbstractItemModel]( API, and all
[QTreeView]( widgets share that model.

@ -0,0 +1,35 @@
Title: Development update (June 23)
Date: 2019-06-23
The [latest
commit]( just
adds a single node type.
### What's new
#### MIDI Looper node
This node can record a few beats of MIDI events and plays them back in a time-synced loop.
For now only the most basic features are implemented. I plan to do another pass on this node at some
later time to extend the features (e.g. multiple "patches", editing MIDI events in the pianoroll
widget, etc.).
It does feature a new pianoroll widget, which is just read-only for now and displays the recorded
MIDI events. After adding editing features to this widget, I might be able to reuse it for a
pianoroll track, which I'm planning to add anyway.
And it is the first time that noisicaä can record something in
realtime. Consider this a first prototype of future recording capabilities.
### Bug fixes
* There were `.pyi` files missing for two cython modules. After adding those, `mypy` uncovered some
minor bugs.
### Internal changes
* Initial infrastructure showing the node UIs in a dialog window. That needs some more
work. Eventually it should be possible to pop out the UI to a window for every node.
* Some infrastructure to persist Qt properties in the project's session data.

@ -0,0 +1,93 @@
Title: Development update (July 6)
Date: 2019-07-06
Today's [commit]( has a number of new node types. And pictures!
### What's new
#### Metronome
[[thumb:2019-07-06-metronome.png]] The simplest imaginable metronome. It just makes a tick on every
beat (if playback is running). But you can select the sample that it should play. The audio is not
sent directly to your speakers, you have to wire it up just like any other node.
#### MIDI Monitor
[[thumb:2019-07-06-midi-monitor.png]] The MIDI Monitor just displays a list of the MIDI events that
it receives on its input port. Inspired by [KMidimon](, but much
simpler. I mostly wanted it for debugging of other MIDI nodes.
#### MIDI Velocity Mapper
[[thumb:2019-07-06-midi-velocity-mapper.png]] The MIDI Velocity Mapper takes a stream of MIDI
events, tweaks the velocity of `noteon` events (other MIDI events are left untouched) and then just
passes them through to its output port.
The main motivation is the little [AKAI APC Key 25]( MIDI
controller, which I have on my desk and sometimes use to feed MIDI data into noisicaä (or any other
audio software). It's nice, because it's small and always in arms reach, if I want to doodle
around. But the keys are IMHO not very good. They feel pretty cheap and I have to hit them very
hard to get even a medium velocity out of it. Perhaps that's ok for professional musicians, or
when you're on stage and pumped up with adrenaline. But for a bloody amateur like me, who has
trouble even hitting the right keys, that makes it very hard to use. Putting more energy into my
fingers just reduces the precision and I keep hitting multiple keys at the same time. The Velocity
Mapper basically allows me to adjust the sensitivity of the keyboard.
#### Control Value Mapper
[[thumb:2019-07-06-cv-mapper.png]] The transfer function, which I implemented for the MIDI Velocity
Mapper, was implemented in a way, which is easy to reuse elsewhere. So I just added another node,
which applies such a function to an a-rate control value.
The function just maps some input value to an output value. It currently supports three different
"Fixed value:" As the name suggests, the output is always a fixed value. Not very useful for control
values, but it makes more sense for the MIDI Velocity Mapper, where you might want to just ignore
the incoming velocities.
"Linear:" Useful for mapping e.g. a [-1,1] signal to [0,1].
"Gamma:" This uses the same function as the "Gamma Correction" known in image processing (or your
monitor settings). Basically brightens or darkens a signal, while still maintaining the full value
#### Oscilloscope
[[thumb:2019-07-06-oscilloscope.png]] This should mostly work like a real oscilloscope. I
think. Because I never used one.
I felt the need to add this one, because while testing out the Control Value Mapper something "did
not sound right". But without being able to visualize the signals, I couldn't tell what the problem
was. It turned out that Csound's [lfo]( opcode does not
work as I expected. The manual makes it look like it can produce both k- and a-rate signals. But it
turns out that even when using it with a-rate output, the actual value is only computed at
k-rate. So what I heard was basically an LFO with a super low sample rate.
Currently you can only feed a-rate control values into it.
### Internal changes
* Created a base class for testing processors, removing a bunch of code, which I duplicated over and
### What's next?
While working on those new nodes, it became quite annoying that ports have different types that you
can't easily connect. E.g. plugins generally use k-rate control values for their controls, whereas
my builtin nodes prefer a-rate control values. So if I have an LFO producing an a-rate output, I
can't use it directly to feed some control of a plugin. Or the Oscilloscope should also be able to
display audio data. And so on.
In some cases it can make sense to allow connections between ports with different types. A k-rate
control output could just be interpolated to feed into an a-rate control input. An audio output can
feed directly into an a-rate control port (not the other way around, because control values can be
in any range, and you really don't want to feed that into your amp). So noisicaä could do some
auto-conversion has needed.
Or nodes could be able to accept different connections to their ports. E.g. the Oscilloscope would
declare that its input port can accept k-rate and a-rate control values as well as audio
signals. And then just process that input appropriately. But that capability would be limited to
builtin nodes, because plugin don't know how to do that.
So that's probably what I'm going to work on next.

@ -0,0 +1,39 @@
Title: Development update (July 14)
Date: 2019-07-14
This [commit](
implements most of what I was talking about [last week](/blog/2019/07-06-development-update).
### What's new
#### Variable type ports
Ports can now be declared with multiple types. Two ports can be connected, if they have at least one
type in common.
This feature is currently used for
* the Oscilloscope node, so it can also graph audio and k-rate control signals.
* the Oscillator node, so its input and output ports can be connected to any audio or a-rate control
More nodes should make use of that feature in the future. Ideally this should remove the pain of
constantly thinking about k-rate vs. a-rate control signals, but this feature is limited to builtin
nodes. So I might still need some way of automatically converting between incompatible port types. I
still don't like the idea of an implicit conversion of a-rate control signals to k-rate, because
that's a lossy conversion. But I also expect that to be frequently needed, because plugins generally
use k-rate control values for their controls.
### Internal changes
* Processors now get references to `Buffer` instances, instead of raw data pointers. The processor
can query the type of the buffer to determine which of the declared types is actually being used.
* Tracking the connected buffers is now done completely in the `Processor` base class. Subclasses
just had a lot of trivial code to reimplement the same thing over and over again, but there was no
real need for that level of customization.
* Refactored tests for processors, removing a lot of redundant code. Because of this, this commit
even has a slightly negative line count!
* Connections now track their type. This change is compatibility breaking.

@ -0,0 +1,125 @@
Title: waf migration
Date: 2019-07-20
I could not resist and spent the last few days converting the build system from
[`cmake`]( to [`waf`](
Surprisingly the resulting
[commit]( has a
negative line count, even though the new system has some new features.
I was never really happy with `cmake`. I needed a proper build system, because noisicaä isn't a pure
`python` application (which most of the other things are, that I do in my spare time). For the
initial prototype I got away with using `` to build the few `cython` extensions, but I
quickly grew out of that. My usual choice would have been good, old
[`make`](, but one of the common patterns of noisicaä development
is to upgrade my toolbox and try something more modern. `cmake` advertises itself as modern, fast
and flexible, and it's used by a lot of large open source projects. So I decided to give it a try.
And it's certainly easy to use for `c++` projects - everything needed for that is
built-in. But my case involved a mix of `python`, `cython` as well as a bunch of custom build rules
to auto generate various files, e.g. using `csound`, `faust`, etc. To define such custom build
rules, you have to dive deep into `cmake`'s language and that's the part that turned me off.
`cmake`'s language feels like a reanimated corpse that dies a few decades ago. It's a macro
language, there are no proper functions, so "return values" are written to some kinda global
variables. While you can get everything done somehow, it feels really quirky.
Also `cmake`'s distinction between files and targets was very confusing to me. Only target can have
dependencies on other targets - at least that's how I understood it. I could never really wrap my
head around it, so I have probably created a lot more targets than necessary.
`waf` is not without it's own quirks. Part of that might be due to compatibility requirements. On
the one hand compatibility with older versions of `waf`, i.e. the usual accumulation of cruft that
you see in any non-trivial application. On the other hand compatibility with old `python`
version. E.g. `waf`'s `Node` class looks a lot like
[`pathlib`](, but it cannot use it as long as it
wants to stay compatible with `python` versions before 3.4. And because it wants to be both self
contained and small, it can't just use packages outside of the `stdlib`.
But the biggest selling point of `waf` is that it's `python`. Instead of some half baked custom
language, you have the full power of a proper general purpose language at your fingertips.
Converting the existing build logic over to `waf` was pretty painless. Basically just rename all
files to [`wscript`]( and
make some fairly mechanical syntax changes. Most of the work was reimplementing the various custom
rules to `waf`. That turned out to be a bit more
[verbose]( in terms of line count,
but that's more than compensated just by expressing the logic in a proper programming language.
The only significant difference should be that I never got dependencies of `cython` modules right in
`cmake`. Every once in a while I made a change that should have triggered a rebuild of some `cython`
modules, but that never happened - resulting in runtime errors. Getting that right in `waf` was very
straight forward.
Once I did the basic build logic carried over to `waf`, I started looking into things I could do
better now.
### Handling of 3rd party dependencies
One of the things that neither `cmake` nor `waf` (nor any other build system that I know of)
directly support, is the handling of dependencies on 3rd party packages. That's actually something
that could be done with ``, which is more of a package management system than a build
system - at least for other `python` packages (and with a terrible hack, also for non-`python`
Before you can start to build any software from source, you probably need a bunch of libraries,
packages, tools, etc. installed, which are used by those sources. Usually the `configure` step of
the build system checks for these dependencies and fails if anything is missing. It is then left to
the user, possibly directed by some `INSTALL` documentation, to install the missing pieces and try
again. That usually takes a few iterations until everything is in place. That's pretty tedious for
the user, and it's hard to keep the documentation in sync with the actual requirements of the
I used to have a [`listdeps`]( script,
which had all the knowledge about required packages, both `python` packages that are to be installed
with `pip`, as well as system packages to be installed with `apt`. This way the list of required
packages was encoded in a way that did not need human intelligence to decipher. I have fully
automated [tests](, which
perform the installation on a minimal system (running in a VM), thus ensuring that the list of
requirements is complete.
I now took this approach a step further and integrated it directly into `waf configure`. So `waf`
checks if all required packages are present and if not, simply installs them. `python` packages are
downloaded and installed in a virtual environment. System packages are installed with `apt`, which
might trigger a password prompt. Usually the user does not expect `configure` to actually modify the
system, so that behavior must be enabled by some flags.
There were a few dependencies (e.g. `csound`, `protoc`, ...), which are not available as easily
installable packages - usually because I want a newer version that what is available in Ubuntu. For
those packages I used that terrible hack I mentioned above. For each such dependency I had a
[``]( file, which
I could install with `pip`. But instead of having any real sources of its own, those ``
scripts just had the logic to download, build and install the sources of those packages into the
virtual environment. I have now moved that logic directly into
[`waf`](, but
apart from that I'm following the same approach: instead of documenting that you should download and
install library X at version Y, the build system just does it itself.
### Transparent virtual environment handling
As usual for `python` projects, I'm using a virtual environment to locally install 3rd party
`python` packages. And I go one step further and also install locally built versions of `csound`,
`protoc`, etc. there as mentioned above.
The normal process is to first "activate" the virtual environment, so these packages become visible
to `python`.
I now moved the management of the virtual environment into `waf`, so it becomes completely
transparent to the user. It is
[created]( and
[populated]( by
`waf configure` and automatically activated by subsequent uses of
[`waf`]( or when running
[noisicaä]( from the build
### `waf install`
Just out of curiosity I tried out what happens when I run `waf install`. And it turned out that the
changes to get that work correctly weren't that difficult. The trickiest part was again dealing with
those 3rd party packages. For noisicaä to work, it needs those packages and libraries installed with
its own files. I ended up just
[copying]( those
files from the virtual environment into the target `lib` directory.

@ -0,0 +1,92 @@
Title: Development update (August 11)
Date: 2019-08-11
And another
[commit](, which
only improves the development infrastructure, this time focused on testing.
### `./waf test`
I removed the `bin/runtests` script, which collects and runs all tests, and moved that logic into
`waf`, so tests are now run with the command `./waf test`. The main benefit is that I'm getting
parallel execution almost, but not quite, for free.
The drawbacks are:
* Each test module is executed in a subprocess, which causes some overhead. That's specifically
noticeable for the unittests, where the tests themselves are fast and thus the overhead matters
* `pylint` is now also run as a subprocess. `` imported it as a `python` module and
subsequent `pylint` runs could use previously cached data.
* I needed some additional code to store the results of each tests and merge them at the end. For
the unittests I'm using
[`unittest-xml-reporting`]( to write them out as
XML and [`xunitparser`]( to read them back. For `mypy` and
`pylint` I'm just writing/reading plain text files.
* `mypy` needed some extra care, because running multiple `mypy` processes using the same cache
directory causes some race conditions. I have to use a pool of caches, so each cache is only used
by one `mypy` process at a time.
But overall the test suite now runs about twice as fast. Some unscientific benchmarks:
| command | runtime |
| :--------------------------- | ------: |
| `bin/runtests` | 15:49 |
| `./waf test -j8` | 7:16 |
| `./waf test -j4` | 8:36 |
| `./waf test -j2` | 13:58 |
| `./waf test -j1` | 26:31 |
| `bin/runtests --tags=unit` | 0:42 |
| `./waf test -j8 --tags=unit` | 0:23 |
| `./waf test -j4 --tags=unit` | 0:30 |
| `./waf test -j2 --tags=unit` | 0:51 |
| `./waf test -j1 --tags=unit` | 1:35 |
I just used a single run of each command and `/usr/bin/time` for the measurement.
The overhead is about 2x, so you need two cores just to make of for it. Which means that you're
penalized, if you are attempting to do noisicaä development on a single core machine. But I guess
using a single core machine (which must be pretty old) isn't much fun anyway these days.
What is interesting is that there is little gained when going from four to eight cores. That's
probably because my CPU is a quad-core with 2x hyper-threading, but I haven't looked into that issue
any deeper.
Another advantage of running tests in subprocesses is that I can now put a timeout on tests, so if
some test hangs, it will eventually fail and I don't have to kill the main process, thus losing the
actual test report.
### VM Tests
I reanimated the VM tests, which suffered from some bitrot and didn't work anymore. While at it, I
switched from `virtualbox` to `qemu` for the VM, because `qemu` is a bit easier to automate.
These tests launch a VM with a minimal installation of the OS (current only Ubuntu 16.04 and 18.04)
and then build noisicaä from the sources. This is mostly to verify that all dependencies are
correctly declared and the build instructions work as advertised on a system that isn't my
development system.
Once I got the tests working again, they uncovered some bitrot, which caused noisicaä to not work
anymore on Ubuntu 16.04 or Python 3.5.
### `clang-tidy`
The test suite now runs `clang-tidy` over `C++` source files. I previously cranked up the pickiness
of `gcc` (i.e. `-Werror -pedantic`), but that meant that compilation would fail for every minor
issue. Now building became more "pythonic": `C++` source get built, as long as there are no major
issues (with all warnings disabled, i.e. `-w`), and once I want to also have the code "clean" I run
`clang-tidy` over it.
I haven't verified, if the issues that `gcc` would have detected are all covered by
`clang-tidy`. I'm just assuming that `clang-tidy` is "good enough". I also have not yet attempted to
fine tune `clang-tidy` and run it with default settings for now.
### Upgraded `mypy` to 0.720
That version specifically has a new option `warn_unused_ignores`, so I could find and remove
overrides, which used to fix false-positives in some previous version of `mypy`, but were now
obsolete and potentially masked some real issues.
### Removed all build noise
At least with my setup, all random noise generated during the build steps has been removed.

@ -0,0 +1,42 @@
Title: Development update (September 8)
Date: 2019-09-08
Finally [a
commit]( with
some major new feature: Piano roll tracks.
### What's new
#### Piano roll tracks
This isn't exactly an distinguishing feature of noisicaä (as the score tracks would be), but a
pretty standard feature of a DAW, so it's good to have.
For now I just implemented the most basic editing features to make it useful. There's no editing of
CC events, no recording, no importing of MIDI files. One editing feature, which I would consider
"basic", is still missing though: copy & paste. There is some clipboard support in other track
types, but I'm not happy with it, so I didn't want to add more cruft to that. The next thing I want
to tackle is a proper design of the copy & paste system, which should be ready for current and
future use cases.
#### Some minor UI tweaks
* The position of the splitter between the track list and the graph canvas is now persisted.
* The track list stays centered when changing the time scale (`ctrl-left` and `ctrl-right` -
hmm... that's pretty well hidden...).
### Internal changes
* Tracks are now `QWidget`s, which simplifies the UI event handling and allows to use the existing
`PianoRoll` widget to be used for the MIDI segments.
* Extended the existing `PianoRoll` widget (as introduced for the [MIDI
Looper](/blog/2019/ node) to support editing and multiple MIDI
* The existing `PianoRollProcessor` has been extended to handle multiple segments, so it can be used
by the new `PianoRollTrack`, while keeping compatibility with existing uses by `ScoreTrack` and
* The tool-based UI event handling has been streamlined.
* I switched to using `QAction`s with shortcuts, instead of explicit keyboard event handling, to
trigger keyboard shortcuts (after I figured out how to make that work properly).

@ -0,0 +1,92 @@
Title: PySide2 non-migration
Date: 2019-09-22
I was about to finish another sprint (implementing a saner copy&paste system, as I [hinted
earlier](/blog/2019/ So I ran `mypy` over the sources and saw that it
complains about a bunch of things, which are caused by an issue with `PyQt5`.
`PyQt5` seems to not like classes, which explicitly inherit from multiple "`Q`" classes.
E.g. something like that:
class SomeMixin(QtCore.QWidget):
def someMethod(self):
class SomeLineEdit(SomeMixin, QtCore.QLineEdit):
`QLineEdit` is a subclass of `QWidget`, so the above should be perfectly fine. But not for
`PyQt5`. When I tried to make a minimal example, it just segfaulted, but I vaguely remember seeing
some exception being raised. To workaround that, I had to make such mixin classes not inherit from a
"`Q`" class (e.g. just `object`), which is perfectly fine at runtime. But `mypy` has no idea that
this mixin is only used with some kind of `QWidget` and that `self.update()` is a valid method. So I
have to make `mypy` suppress all those false-positive warnings, which makes the code look ugly, and
I lose type checking for any real issues.
Besides that `PyQt5`'s support for type annotations was not so great anyway. I'm maintaining my own
set of stubs for it, which are based on the original `PyQt5` stubs, but with lots of manual tweaks
to make them actually useful.
So when I saw that `Qt` now [officially includes Python
bindings]( in the shape of
[`PySide2`](, I was interested in evaluating a migration. There was
an open [ticket for adding stubs](, but that was fixed
for version 5.13.
It's easy to install via `pip`, so I made a quick test to see if `PySide2` was also suffering from
the inheritance issue above. It wasn't, so let's give a real migration a try.
`PySide2` looks sufficiently similar to `PyQt5`, that you could think a simple `s/PyQt5/PySide2/`
might already be enough. For some projects it might already be that, plus some more trivial renames
like `pyqtSignal`&rarr;`Signal` or `pyqtProperty`&rarr;`Property`.
But there are more subtle differences, which make it much harder (at least for noisicaä)...
* The `connect()` method of signals returns a boolean. Apparently it can fail (no idea under which
conditions...), so you should probably check the return value. Which is very unpythonic - it
should just raise an exception. And in `PyQt5` it returns a `Connection` instance, which can be
passed to `disconnect()`. That's the only way to disconnect a `lambda` function (without carrying
a reference to that function around), which I do a lot, so that's annoying.
* The way how a class level `Signal` attribute gets turned into an instance level `SignalInstance`
attribute looks odd. In `PyQt5` the `pyqtSignal` implements the property protocol, so accessing
the attribute on an instance returns the appropriate `pyqtBoundSignal` instance. In `PySide2` the
metaclass does somehow create a `SignalInstance` for each `Signal` and [injects that into the
though I haven't really figured out when this actually happens. The problem for me is that there
doesn't seem to be a way to get from an `Signal` instance and the owning object to the
`SignalInstance`. Which I do in some helper function, which saves me a lot of boilerplate code. I
could find a workaround, but that is really ugly... Parsing the `str()` of the `Signal`
instance... I won't say more. Too embarrassing.
* Signals cannot use [an `Enum` as the type]( That bug
is already 5 years old and for an ancient version of `PySide`. The workaround is to declare those
signals with type `object` (and lose some type safety).
* `QSettings.value()` does not return the default value, if it is `0` or `False`. That seems like a
plain and simple bug.
Those are the issues, which I have found so far. At least the unittests are now passing, but that
doesn't really mean that much, because the test coverage for the UI code isn't that great. And
getting there wasn't easy, because `PySide2` is also very crash happy. So instead of a nice Python
exception telling me where and what was wrong, I just got the unhelpful "Segmentation fault (core
dumped)" message. I had to perform the "install from source" dance to get a version with debug
symbols, so `gdb` could at least tell me something about the problem.
And now I'm getting this exception:
Traceback (most recent call last):
File "/home/pink/noisicaa/build/noisicaa/ui/", line 62, in __init__
TypeError: connect() takes 3 positional arguments but 4 were given
Sorry, but that simply does not make sense.
It would have been nice to have a viable alternative to `PyQt5`, and perhaps `PySide2` is that, if
you're starting a new project from scratch. But migrating noisicaä does not seem worth the effort,
at least not now. There is at least some hope that development of `PySide2` gets a boost, at least
for a while, now that it has been included in the `Qt` canon. Let's give it some more time.

@ -0,0 +1,38 @@
Title: Development update (September 23)
Date: 2019-09-23
As [mentioned before](/blog/2019/09-08-development-update) I worked on the copy&paste system, which
has just been
### What's new
The only user visible change is that you can now copy&paste segments in piano roll tracks, as well
as MIDI notes within segments.
### Internal changes
noisicaä now uses the system clipboard (via `Qt5`'s API) to store the copied items. The items are
serialized in a common protobuf message, with extensions for the various things that can be
copied. That new system has been used to add copy&paste support to piano roll tracks and the
existing copy&paste functionality for score and beat tracks has been migrated to it.
There is now a single class, which keeps track of the clipboard contents and the current focus
widget. It also owns the `QAction`s for "Cut", "Copy", "Paste" and "Paste as link", and decides
which of these actions are enabled based on the current state. If one of those actions gets
triggered, it is sent to the current focus widget, which then implements the actual business logic.
That seems to work pretty well, and the code looks much cleaner than the previous dispatching of
method calls. But I'm not 100% sure that I covered all cases in which the state of the actions needs
to be updated. I have the feeling that there are conditions in which e.g. "Copy" should be enabled,
but isn't, or vice-versa.
Another thing where I'm not quite finished is how the sets of selected items are managed. Currently
the three widgets, which do support selections, implement that independently. So there's a bit of
repetitive code, which is quite similar, but with more or less subtle differences. Some of those
differences should be removed, so all widgets exhibit the same behavior (which is currently quite
inconsistent, including very different colors to highlight selected items). But other differences
are inherent to the nature of those widgets. E.g. items, which are lined up on a linear time line
(like segments on a piano roll track) are different from items places on a two dimensional canvas
(like notes in a piano roll segment or nodes on the pipeline graph canvas). I'd like to get a
better feeling for what should be shared and what is specific to each widget, before I try to come
up with some class that factors out the selection management.

@ -0,0 +1,57 @@
Title: Development update (January 3)
Date: 2020-01-03
There hasn't been an update in a while. And there hasn't been a lot of work on noisicaä either.
I started a new sprint back in September, but then there was a vacation, and that yanked me out of my
routine, and it took me an awful long time to find my way back.
It wasn't like I was not doing anything. I spent some time improving my emacs configuration,
including setting up a configuration for my daughter's novel writing ambitions. We bought one of
those all-in-one printer-scanner-fax[^1] things, which triggered me to write the beginnings of a
little document management system, so we can eventually move to a (mostly) digital archival for
documents that you're supposed to keep. I reinstalled my dying home server on a Raspberry Pi 4,
which went surprisingly smooth.
But those were the kind of in-between projects that you do to distract yourself, not something to
focus. But perhaps that is just what I need every once in a while, as I feel that I have rebuilt
quite a bit of energy over the past few days. Now I "just" have to direct that energy towards
Anyway. Just to wrap up the stuff that I was doing (mostly back in September), here's the latest
There are still plenty of bullet points on my checklist, which I initially planned to do in that
sprint, but I'll defer those to another time.
Even the commit was already done three weeks ago, and I couldn't get myself to write the
accompanying blog post until now.
### What's new
#### Track list improvements
[[thumb:2020-01-03-track-list.png]] I did quite a bit of refactoring and improving of the track
list. Tracks can now be resized vertically and reordered with drag-n-drop. There's also a new zoom
function which zooms in both dimensions, but that's only accessible via keyboard shortcuts with no
visible hint that those exist. And so far only pianoroll tracks currently handle resizing correctly.
#### Load test projects
[[thumb:2020-01-03-loadtest-project.png]] There's a hidden feature (I'm not telling you how to
access it &#8212;&nbsp;read the source to find out) to create a new project filled with random
data. This is really just a development tool for myself, so the usability is not that great and that
won't change. Like the name suggests, I can use this feature to stress test noisicaä and find
performance bottlenecks.
### Internal changes
- Some refactoring of the process startup, which previously triggered some scary warning messages
(`"RuntimeWarning: 'noisicaa.core.process_manager' found in sys.modules after import of package
'noisicaa.core', but prior to execution of 'noisicaa.core.process_manager'; this may result in
unpredictable behaviour"`).
- A new `move` mutation type to efficiently reorder lists.
[^1]: Yeah, that stuff is still around. I have no use it or intend to even plug it into a telephone
socket. But it's not like we wasted money on a feature that we're not using, given how dirt
cheap the hardware itself is &#8212;&nbsp;until you have to buy the first toner refill.

@ -0,0 +1,41 @@
Title: Development update (February 21)
Date: 2020-02-21
Took a while, but I finally managed to kick myself back into a more productive mood. It was just a
matter of getting started, but as usual that's the hardest part.
So here's the [latest commit](
There were also some more commits to the master branch afterwards, but those were just maintenance
work, i.e. upgrading the package dependencies, incl. `mypy`/`pylint`, which triggered some code
cleanups. I just did not bother to create a new branch for that.
### What's new
#### Sample track improvements
[[thumb:2020-02-21-sample-tracks.png]] I made various improvements to the sample tracks (which I
should really rename to "Audio Track") to make them at least somewhat usable - for my current
purposes, which is to just import an existing song and then try to decompose it into its parts and
rebuild those using noisicaä. I.e. I do not need anything fancy, just the ability to import an `MP3`
or `FLAC` file into a track and play it back. And do that without the UI blowing up.
Audio files are either read with [`libsndfile`]( (like before)
or piped through [`ffmpeg`]( for formats like `MP3` or `AAC`.
To get reasonably performant rendering, the audio data is split into chunks, which are rendered
asynchronously and then cached. Even though the main number crunching is done by
[`numpy`](, reading directly from a mmap'ed files, you still notice that this is
`Python` (i.e. it could benefit quite a lot from a `C++`/`Cython` version).
The audio data is rendered as [`rms`]( and min/max
(should be the same way as [`Audacity`]( does it). And stereo files
are now correctly rendered as well.
There are still no advanced features, like editing, enveloped, disk streaming, etc.
### Internal changes
* Audio files are now decoded into raw files (32bit floats, single channel per file) into the
project directory, which can be directly loaded into memory for playback.
* Some test coverage improvements.

@ -0,0 +1,33 @@
Title: Development update (February 22)
Date: 2020-02-22
Oops, already the [next
commit](, though
not a very big one (and I have to admit that I was already working on it when I wrote yesterday's
### What's new
#### New toolbar
[[thumb:2020-02-22-toolbar.png]] The toolbar has been redesigned. Instead of using the normal
`QToolBar` widget, this is now using a custom layout. I rearranged the buttons, added buttons to
move the playhead back and forward by a single beat, added a widget to display the current time
(both in musical time and wall time), added a VU meter to display the master output level and move
the engine load graph from the status bar at the bottom of the window into the toolbar.
#### VU Meter node
[[thumb:2020-02-22-vumeter.png]] A simple node with just a VU meter display. I just needed the
processor, which is invisibly added to the engine in order so send the master output level to the
toolbar. Adding a UI to it and thus making it available to the user was simple enough.
#### Snap-to-grid when moving the playhead
Not much more to say about this.
### Bug fixes
* Some previous refactoring broke the status updates of the playback and loop buttons.
* The time alignment of measured tracks (Beat and Score tracks) got out of sync with the other
tracks due to rounding errors.