Category Archives: Software

Interesting tools

Requirements for a Metronome App

Every now and then I use a metronome while practising. I still have a traditional, spring loaded metronome available. Somewhere I must also have a digital device from the 90ties.

It was always tempting to place the metronome on top of the instrument while practising. But what I learned was that a moving pendulum or blinking LEDs distracts the player from the acoustic signal, the sheet music and the instrument. So one habit of mine was to place the metronome outside the reach of my eyes.

Since we have modern handsets at our disposal at almost any time, an app was a perfect solution. Here are a couple of requirements I have in mind:

  • Absolutely precise timing. There are many apps available, but several have difficulties coping with this non functional requirement.
  • Distraction free user interface. This removes all apps from the remaining list that are based on ads or contain animations like moving pendulums or blinking user interface elements.
  • Straightforward usage. One of the apps I used had a lot of features so that the start/stop button was difficult to locate. And when trying to start the metronome, it complained that I had to configure a couple of settings first.
  • Great user experience. The basic features should be as simple to use as possible. The Start/Stop button should be big enough to use it even at a distance of an arm.
  • Pleasant timbre. I know, de gustibus non est disputandum. But plain sine or square waves IMO sound cheap.

I really liked the Soundbrenner user interface approach, but unfortunately it failed as per the topmost and the second requirement.

After a rather long survey, I found the code of Bad Metronome, which actually provides the precision required. Ironically it provides a control to add some randomisation to its precision :) . I’m currently experimenting with the code so as to learn more about Android programming.

An obvious issue of BadMetronome is that it runs at twice the speed configured. The issue is that the code assumes that 1 sample is expressed in one byte, but actually it’s two of them. In I thus added
beatLength = beatLength * 2;
below the line
int beatLength = (int) Math.round((60.0/bpm)*audioTrack.getSampleRate());

Using OsmAnd and for a short vacation

For the latest trip I once again used Android apps that make use of Openstreetmap data for offline Navigation. This included three uses: car navigation (routing), hiking support (display a prerecorded track), and finding POIs inside a small town. I used OsmAnd and In short, I prefer the former for hiking and the latter for car navigation. As with any other tool, both have strenghts and weaknesses. focusses on ease of use. Compared to OsmAnd, it is much faster calculating routes. It can also display tracks on top of the map, but only in kml format, not the popular gpx format. Like OsmAnd, it provides synthesized speech output for turn instructions. However, those alone are not reliable enough to reach the destination without deviations. A car mount for the handset is mandatory so that the driver can see the route on the display at crossings.

Unlike OsmAnd, stops routing in case the display is switched off. This means the driver cannot switch off the display on highways when the next turn is far ahead. Not to talk about the ability to automatically switch on the display as soon a turn is approaching. That would be great when driving without daylight.

For car routing, remains my favourite, mainly due to its overall ease of use.


OsmAnd feels like a swiss army knife. It can do almost anything one might expect of a mapping application. It features a highly configurable map with several overlays (SRTM contour lines, hillshading, POIs), can import and export tracklogs, supports car, bike, and pedestrian routing and can even warn when violating speed limits. Its routing engine can also cope with stopovers.

Over the years, it became more and more easy to use, despite its many features. On the other hand, those features require a certain amount of controls, while some features are well hidden in some sub menus (I detected one just a couple of days ago).

Its routing engine is rather slow and has difficulties coping with long distances. As a former MoNav developer, I really wonder why none of the routing apps seems to be aware its “realtime” routing engine, which is available for about 7 years now.

Due to its stopovers, I’m still struggling with basic routing like “Just route me back to my hotel.”. In the car mount, the display often is flickering a lot, the handset becomes rather hot and the battery tends draining. Where I love it is during hiking trips. Switch off the phone’s display, put the handset into the pocket and grab it at the next crossing. OsmAnd is still running, did continue to record the tracklog and immediately shows the current location. One can even add waypoints to the current tracklog (though it requires a couple of clicks). I simply love it for that purpose.

OsmAnd also warns about railroad and pedestrian crossings. The latter ones became rather annoying in case multiple of them follow each other. At leat OsmAnd should not announce the next before the first was passed. The current implementation made me mute the car’s hifi system completely.

I got the impression that the POIs in OsmAnd only contain POIs which are present as nodes in the openstreetmap data set. POIs that are mapped as polygons (e.g. shelters while hiking or churches) are not part of the POI set.

Phantom turn instructions

Both OsmAnd as well as provide phantom turn instructions. I haven’t figured out yet what is causing those issues, but since both applications suffer from it, it is likely based in the OpenStreetMap data set. Unfortunately, I haven’t figured out the reason yet.

What happens is that both apps tend to say something like “turn left” or “turn slightly right” while driving on a road where no crossing exists at all. I observed this behaviour every now and then, e.g. excessively between this point and Echternach a couple of days ago. Checking the data didn’t show any abnormality, except that the street’s path contains some very short segements every now and then. also suffers from this issue. Today it two times told me “turn left” – in the middle of a highway bridge (like the Sauertalbrücke). A driver following such instructions should face the consequences :) . Unlike the aforementioned way, the bridge does not contain short segments, so I have no clue what actually is causing those mysterious turn instructions.

Die Länge von Audiodateien ermitteln

Mittels soxi lässt sich die Länge von Audiodateien auf der Kommandozeile ermitteln. Der Schalter -D liefert die Länge in Sekunden, -d in Stunden, Minuten und Sekunden:

soxi -D *.ogg

soxi -d *.ogg

Der Notenanzeiger – zurück zum Papier

Von 2015 bis zum Sommer 2016 bestand mein Repertoire noch aus wenigen Stücken, die nicht länger als drei Seiten waren. Ich hatte sie ausgedruckt und nebeneinander aufs Notenpult gestellt. Das war zum Spielen praktisch, die Zettelwirtschaft erfordert früher oder später aber letztlich doch ein geeignetes Ablagesystem.

Inzwischen habe ich mich an drei längere Werke von sechs, acht und zehn Minuten gewagt. Die Noten bestehen jetzt aus deutlich mehr als drei Seiten. Ich habe die Stücke, nachdem die Fingersätze erarbeitet waren, ausschließlich mit einem Tablet, das annähernd A4-Größe bietet, gespielt. Es war initial nicht ganz einfach, eine funktionierende Werkzeugkette aufzubauen. Liegen die Noten aber endlich digital auf dem Tablett, komme ich bisher ganz gut damit zurecht. Vor allem bei längeren Werken finde ich das Umblättern am Tablet deutlich einfacher als physische Noten umzublättern. Allerdings gibt es immer wieder Noten, bei denen man weder mit Papier noch mit dem Tablet geeignete Stellen zum Blättern findet. Teilweise habe ich mittlerweile Stücke neu gesetzt, damit ich Einfluss auf diejenigen Stellen nehmen kann, an denen Umgeblättert werden muss.

Nach wie vor habe ich aber auch zwei- und dreiseitige Werke, bei denen es im Spielverlauf nahezu unmöglich ist, umzublättern. Das gilt vor allem für das Caprice sur les Grands Jeux von Clérambault, bei dem man mit dem Spielen derart beschäftigt ist, dass an ein Umblättern nicht zu denken ist.

Ich habe mir daher via mein derzeitiges Repertoire in ein Büchlein drucken lassen. Zweiseitige Stücke liegen jetzt grundsätzlich auf einer Doppelseite, so dass Blättern komplett entfällt. Von dreiseitigen Werken habe ich nur die ersten beiden Seiten auf eine Doppelseite drucken lassen. Die dritte habe ich selbst ausgedruckt und mit Klebeband so eingefügt, dass ich sie zu Spielen ausklappen kann. Auch hier entfällt das Umblättern somit komplett.

Die längeren Werke habe ich auch in das Buch aufgenommen. Während ich aber mit dem Tablet so schnell blättern kann, dass der Spielfluss erhalten bleibt, gelingt mir das mit Papier überhaupt nicht. Ich werde also für längere Werke beim Tablett bleiben.

Obwohl ich ein Tablett mit ganz ordentlichem Display gefunden habe, ist der Kontrast des Druckwerkes, zumal das Papier matt ist und keinerlei Blend- und Spiegeleffekte auftreten, deutlich besser. Für einseitige Stücke werde ich daher ebenfalls beim Papier bleiben.

Diakritische Zeichen in Unicode

Auch in Unicode gibt es mehrere Möglichkeiten, diakritische Zeichen darzustellen. Stark vereinfacht ausgedrückt kann ein Zeichen als selbstständiges Zeichen (»Ich bin ein Ä«, Normalization Form C, abgekürzt NFC) oder als zusammengesetztes Zeichen (»Ich bin ein A mit zwei Punkten darüber«, Normalization Form D, abgekürzt NFD) ausgedrückt werden.

Ich nutze ein Python-Skript auf Mac OS X, um automatisiert aus Dateinamen Tags für Ogg-Vorbis-Dateien zu generieren. Im Dateinamen von OS X liegen die diakritischen Zeichen als NFD vor. Um die Zeichenkette in NFC zu überführen, nutze ich folgenden Aufruf:

filenameNFC = unicodedata.normalize("NFC", filenameNFD.decode("utf-8"))

MIDI recording using an Android device


Raspberry Pi 3

I used a Raspberry Pi 3 on top of one of my musical instruments to send program changes, record and playback MIDI as well as recording audio. A cardboard box did host the computer, its touch screen, the power supply, and a lot of cables went out of it (power chord, two MIDI chords, two audio chords, and sometimes a mouse and kayboard connected via USB).

Recording MIDI via Bluetooth LE on Android 6

I wanted to get rid of most of the hardware required by using an Android 6 device with its Bluetooth LE MIDI capabilities. I was looking for a basic MIDI recording application. Rather surprisingly, there was none that did fulfill my essential needs (simply record any MIDI message incoming via Bluetooth).

Recording MIDI via USB using Audio Evolution Mobile Studio

So I looked for apps that at least can record MIDI via USB. It turned out not to be an easy task. I finally selected Audio Evolution Mobile Studio. Of all the apps I inspected, it was the one that is closest to a traditional digital audio workstation.

It doesn’t use the native Android 6 MIDI subsystem. As a consequence, it can’t cope with MIDI over Bluetooth. So I’m still stuck with an USB OTG cable, a power supply for it, and a MIDI to USB cable. Additionally, USB MIDI support is not included when purchasing the app. A further “In-App” purchase is required to unlock this feature. Unfortunately it didn’t accept my preferred USB to MIDI device, the excellent Edirol UM-1S. It did accept the cheap device I bought I couple of months ago, though. This leads to a couple of issues. Firstly, the instrument in question sends a couple of program changes before recording. They appearently all arrive at the handset (since they appear in the MIDI file exported from Audio Evolution Mobile Studio). However some of them get lost each time I playback the MIDI file. Furthermore, the instrument sends a MIDI system exclusive command to reset all program changes before the actual program changes. This command does either not arrive at Audio Evolution Mobile Studio, or it denies recording them.

Audio Evolution Mobile Studio supports the traditional three track types: Audio, virtual instrument, pure MIDI. When pressing the record button, Audio Evolution Mobile Studio automatically creates a new audio track in case no other track is present or switched to recording mode. This behaviour can be switched off via the preferences.

When it comes to MIDI recording, the app shows some neat features that perfectly fulfill my needs. I created four MIDI tracks to record the Kisselbach Gloria Klassik 240. One for the Main organ (MIDI channel 1), one for the swell (MIDI channel 2), one for the pedal board (MIDI channel 3), and one for the program changes plus the volume controller (MIDI channel 12). Audio Evolution Mobile Studio allows to enable recording for multiple tracks at once, plus it allows to choose for each track which MIDI channel should be recorded by it. I was pretty impressed to detect this feature set, since I assume it is a very exotic request that someone wants to record multiple MIDI channels at once.

I already recorded some piece and exported it to MIDI. Obviously it didn’t write the track names to the MIDI file. But otherwise, everything seemed to work fine.


Appearently Audio Evolution Mobile Studio does the one thing I need quite well. However, I did not get rid of the cables since it does not support the native MIDI subsystem as instruduced in Android 6. Further, it seems to ignore SysEx data and ignores track names when exporting MIDI. The latter two mean that I have to circumvent those issues by manually editing the resulting MIDI files. It’s annoying, but not really an issue.

Taking into account the many features the app provides, the price tag seems to be OK. For my needs, it’s a bit too expensive (not to mention the extra fee for the MIDI recording feature). I decided to buy it anyway due to the lack of alternatives.

Lineage OS (Android 7.1.1) for a Samsung Galaxy S3


I wanted to learn more about Android Nougat 7.1.1. I decided to install it on a Samsung Galaxy S3. The following is what I recall so far.

Installing Team Win Recovery Project

  • Download and install the Samsung Driver for Mobile Phones (
  • Download and install Odin3 (
  • Download Team Win Recovery (twrp-3.0.2-2-i9300.img)
  • Switch on the S3 while holding the volume down, home and power button pressed. Confirm download mode by pressing the volume up button. Connect it via a USB cable. Warning: Make sure to use a quality cable. The first cable I used did prevent the S3 to appear in Odin3.
  • Start Odin3 in admin mode and transmit twrp-3.0.2-2-i9300.img to the S3.

Installing Lineage OS

  • Download Lineage OS (
  • Optionally download Google apps. I’ve chosen ARM 7.1. nano since all I was interested in was Google Play Store support.
  • Copy both files to the root fo the phone’s built-in SD card.
  • Boot the phone into Recovery (switch on the S3 while holding the volume up, home and power button pressed.)
  • Wipe Cache, System and Data partitions.
  • Flash Lineage (and optionally Google apps) by selecting the files from the phone’s flash memory.
  • Reboot the phone.

That’s it, basically.

MIDI recording using an Android 6 device


Surprisingly I didn’t find any app to record the pieces I play via MIDI (not to mention playback). Though I found a fistful of suitable apps, they still show some drawbacks. Most do not provide native Android 6 API support so I’m stuck to USB (heck, I wanted to get rid of the cables). And even via USB, the apps I tried (like the excellent Samsung Soundcamp) all force the incoming MIDI events to one channel. Unfortunately, my instrument sends events on 4 channels (2 keybeds, one pedalboard, channel 12 for controller data), so the recordings become rather useless.

And since I wanted to actually play the instrument rather than writing code, I do resist the temptation to write an app by myself. At least for the moment :) .

MIDI in Android 6


Android Marshmallow (v6, API level 23) features a more advanced MIDI API. Phil Burk has written a suite of example apps. Two of them, MidiScope and MidiSynth, are “official Google examples”. Martini Moe also made use of the new API and wrote a basic remote control für digital audio workstations.

I played a bit with the tools and code provided, since the new API also adds Bluetooth low energy as a supported MIDI transport medium. This could save me some cables plus the Raspberry Pi I currently use to control one of my instruments. My current verdict reads like “It’s great, though not straightforward yet”.


In order to send or receive MIDI with a handset or tablet, an OTG adapter is required. I tried to connect three simple USB to MIDI interface cables to the phone, but only one worked. At the target device, the commands arrived corrupted. I assume it has to do with the current the phone is capable to offer – a handset usually provides much less than the usual 500mA.

Bluetooth LE

The Quicco Sound mi.1 is a phatastic device. It just gets plugged into the MIDI ports of any instrument, operates bus powered and translates the signal to Bluetooth LE. It worked absolutely reliably during my first tests.

The software part is much more tricky. An application that wants to access bluetooth MIDI devices must gain location permissions. From the docs:

This LOCATION permission is required because it may be possible to guess the location of an Android device by seeing which BTLE devices are nearby.

The application must then scan for available devices and offer a selection to the user. One more quote:

Once the MIDI/BTLE device has been opened by one app then it will also become available to other apps […]

MidiBtlePairing just does this job. Here’s a hint from the docs:

Exit the app by pressing the Home button, not the Back button.

Exclusive device access

In the abovementioned docs, it is recommended to exit any MIDI application by pressing the Back button. Otherwise the MIDI device is still occupied by the application (at least in case it was written as intended) and not available to other devices:

Exit the application by pressing the Back button.

Actually I tested a couple of applications which did not release the device properly. Add to that the occasional loss of bluetooth connectivity every now and then, it isn’t suprising that the user experience is not that straightforward (First run MidiBtlePairing to make the device accessible, then run an app, then run another app and notice the bluetooth device isn’t availble, retry, reboot, etc.).

Further issues

According to, Android 6 features a nasty bug which will be fixed in Android 7:

The MidiManager.unregisterDeviceCallback() method was not working. So if an app was rotated, and the Activity destroyed and recreated, the DeviceCallbacks would accumulate in the MidiServer. This would result in multiple callbacks whenever a device was added. This class allow an app to register and unregister multiple times using a local list of callbacks. It registers a single callback, which stays registered until the app is dead.


MIDI over Bluetooth LE works in Android 6 and IMO is a really great feature. Users should be willing to figure out how to use the tools, though. For my today’s tests, I had to run the MidiBtlePairing tool, the MIDI application and the task manager several times before I got a usable connection. It then worked reliably, thought.

Ein günstiges USB-MIDI-Interface kann Aufwand nach sich ziehen


Bisher betrieb ich an einem Raspberry Pi eine externe Edirol UA-25 USB-Soundkarte. Die ist wirklich topp und zuverlässig, braucht aber auch eine Menge Platz. Da ich momentan nur MIDI am Raspberry nutze und den Platzbedarf reduzieren wollte, erwarb ich ein günstiges USB-MIDI-Kabel für rund 12 €. Wie befürchtet funktionierte das nicht sonderlich gut – die Daten werden teils verfälscht übertragen. So führt beispielsweise das mehrfache Absenden einer Reihe der immer gleichen Programmwechselbefehle am Zielgerät zu sich ändernden Programmaufrufen.

Da ich das Kabel nur genau für diesen einen Zweck verwende und es auf ein paar Millisekunden nicht ankommt, lasse ich meine Software jetzt nach jedem Programmwechselbefehl eine kurze Pause einlegen. Das war relativ zügig erledigt und führte zum Erfolg. Ich kann mir aber nicht vorstellen, dass das Kabel viel Freude bereitet, wenn jemand damit MIDI-Daten aus einem Sequencer an ein oder mehrere Klangerzeuger schicken möchte.

Page turns by blink detection


Recently I got interested in displaying sheet music electronically. I finally chose ComicsReader after adjusting its screen sensitivity a bit, though it requires to convert PDF scores to raster images in a cbz container.

I still dream of some touch free control for turning pages while playing the piano or organ. Voice control could have been an option, but Android currently does not allow application developers to use the built-in speech recognition continuously (but of cource hacks exist to circumvent the limitation).

But Android features face detection via Mobile Vision (though it was unavailable just at the time I tried using it), and most tablets feature a front facing camera. Google provides a tutorial how to use a pipeline to track barcodes and faces. Sample applications are available via Github. nesterov-n also provides a “Smiley” sample application.

The multiprocessor creates a Tracker instance for each face identity detected. Methods like onNewItem(), onUpdate() and onMissing() can be used to retrieve the face objects. The objects contain facial landmarks. Values between 0 and 1 provide information about the probability of smiling or wether the eyes are open. I wanted to check whether one (xor) eye was closed for a certain amount of time and to use this information to turn pages. Thus I used a fifo buffer to collect a certain amount of samples.

I got something to work in a spike, but it still is too unreliable. On the one hand closing one eye for a couple of seconds sometimes does not exceed the thresholds I was using. On the other hand false positives appeared every now and then, accidentally turning pages while playing though the head didn’t move at all.

It’s worth being investigated further, though. I’m currently playing a piece of six pages, and hands-free page turns by eye blinks were more than welcome during the test runs.

Reading sheet music electronically

Cantio belgica

About nine months ago, I restarted playing pipe organs. I focussed on playing, though not exclusively, french composers of the baroque era. The International music score library project hosts tons of free scores in PDF and even MIDI formats. I immediately tried to use electronics to display them, but switched to printing on paper sheets soon since I didn’t find a convincing solution.

Since my repertoire is growing, the desire for a digital solution still exists. Many musicians nowadays use software installed on a tablet to display scores. That’s great for single page scores (like lead sheets). But as soon one page is not sufficient (or the tablet provides a small display), scrolling becomes a mandatory feature. To do so, singers usually can tap on the touch screen to turn pages. Trumpet players can use a wireless bluetooth pedal (like the PageFlip Cicada or the AirTurn). Piano players in a combo still have the option to just drop a couple of notes of the left hand while turning pages.

Unfortunately organ players need both hands and feet to play the instrument, and dropping notes often is not an option. Physically I can at least place two or three sheets of paper (letter respectively A4 size) beneath one another. For longer pieces, it often still is possible to arrange the sheets in a way that they can be turned at a suitable occasion. Further, it is quite easy to add annotations using all kind of stationery. The disadvantage is that it becomes unconvenient to manage the scores as soon as the collection grows, and carrying the stuff around also becomes more and more inconvenient.

The advantage of tablets include the small size, the capability of arranging the required scores in setlists before a gig, sharing scores with annotations within a combo, and at least theoretically making page turns much easier than with physical sheets.

The disadvantage of tablets include the danger of broken displays in case of a fall, the danger of a drained battery and the limitation of the screen size (the typical 10 inches is even too less for displaying one single traditional A4 page).

The only application I know of that provided touch free page turns is piaScore for iOS (demonstration video). Unfortunately the feature was dropped due to technical issues. None of the other candidates (like Zubersoft’s popular MobileSheets or Orpheus for Android devices) has integrated such gestures. Since the tablets usually have built-in mikes, a further workaround could be speech recognition, but I didn’t find any application that included such a feature for page turns. I additionally checked plain PDF readers but to no avail.

Verdict? Using a tablet for displaying scores is an option. It works as long as the score does not exceed the size of one page, or in case the notes are set in a manner that the player can free one of the hands or feet at the end of a page. Even that those conditions are met, a physical backup of the notes is still useful just in case the battery unexpectedly drained or, even worse, the tablet got damaged due to an accident.

I’ll probably start using a tablet for pieces that meet the aforementioned conditions. Not because it really is advantageous, but to stay connected to the further technical development.

Raspberry Pi 3 networking issues

I run a Raspberry for some special purpose application, mainly to record and playback audio and MIDI and remotely controlling some musical instrument. Former hardware revisions provided too little horse power for the task, so the Pi 3 was very tempting. Actually, QTractor now runs without complaining about insufficient CPU frequency, so it obviously was the right decision :) .

The Pi 3 provides two cool new features, both onboard Bluetooth and Wifi connectivity. Thus I bought a Logitech K400 Wireless Touch keyboard (the former model, not the current one) which was just plug and play.

However, I ran into trouble concerning network connectivity. HTTP is very slow. I got none of the NTP applications to work, which is rather painful since the Raspberry provides no battery to keep the time between reboots. ssh is barely usable, since establishing a connection is like some lottery and typing characters via ssh has some severe lagging issues (“5 secs per character!”).

There are a couple of web pages which show that I’m not the only one. For the moment, I gave up in the hope some OS update will improve the situation. Here’s what I tried so far.

Update the operating system

After the issues appeared, I updated the operating system.

sudo apt-get update
sudo apt-get upgrade

To no avail.

Switching to Edimax

The former models I ran had no problems connecting to the network using an Edimax EW-7811UN Wireless USB Adapter. Thus I disabled the internal WIFI adapter by editing


# Disable onboard WIFI
blacklist brcmfmac
blacklist brcmutil
# Disable onboard Bluetooth, if desired
# blacklist btbcm
# blacklist hci_uart

To no avail.

Disable IPv6

Assuming my rather dated router has problems with the default IPv6 connectivity in Debian Jessie, I tried to completely switch to IPv4:


net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1

To no avail.

Disable power saving for the WIFI adapter

Some people reported that disabling the power saving for the WIFI adapter did solve the issues for them. However, a temporary

sudo iwconfig wlan0 power off

does not work for the adapter. The iw command even does not recognize it. iwlist wlan0 power reports that power saving is off already: wlan0 Current mode:off. Anyway I tried to add a line to the interface in /etc/network/interfaces:

iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
wireless-power off

There are several other pages with hints concerning this issue. I dropped ntp and openntp in favour of ntpdate according to Meanwhile, after performing several attempts, I got the time sync working manually using ntpdate -s – once. After a reboot, the internet connectivity is as unstable as before, and the aforementioned command does exactly nothing. I assume this is due to some built-in timeout.

Power Supply

kyuzumaki reports that the power supply may have an impact. I once also had issues with a touch screen not working corrently which I actually solved by attaching a more powerful supply. However, that current issue was not solved by using the official RPI wall wart.


The issue may have to do with changes between Debian Wheezy and Jessie. I did not try to return to the former one. For the moment I’m fine with waiting, since the main issue for my application is that the date is always wrong. I can do all other things I intend to do with the current installation.

A Rasberry Pi and the god of winds…

Despite the low CPU footprint of Aeolus, it turned out that the Raspberry Pi was too weak to run it with many stops “pulled”. Therefore I tried the more recent Raspberry Pi 2 Model B in conjunction with an Edirol UA-25 UB breakout audio box. The first tests look very promising so far.

Here are some configuration hints. The list is neither complete nor free of bugs, since I wrote it after the work was done.

For connectivity, I use the EDIMAX EW-7811UN Wireless USB Adapter. A web search easily unveils the required configuration steps, like this one.

As soon the Raspi is diconnected from its power supply, it will forget about dates and times. I use ntpdate instead of ntp to set this information as soon the OS boots. I used some instruction from this page. It’s in german language, though – je regrette.

Here’s another german page describing how to increase the power of the on-board USB ports. It didn’t help on my machine to cause the low power indicator square at the right top of the screen to disappear. I recommend to use a powered USB hub anyway. Unfortunately some hubs are rather weak in processing certain protocols.

Here’s some stuff I installed:

sudo apt-get install aeolus qjackctl kmidimon vlc-plugin-jack wpagui scrot okular

I use those settings in qjackctl to get stable jack perfomance. The latency is acceptable, though not great. I hope to improve it later.

Persuading VLC to use jack is a bit confusing on german language machines. Choose

Einstellungen, Audio, "Hardware Audioausgabe" (sic!)

To make applications to start automatically after login to LXDE, edit


and enter the name of the application prefixed by an »@«:


Aeolus will compute the “waves” for each particular stop during startup, which can be rather annoying. To avoid that, the waves can be saved to disk via the »Save« button. This, however, requires that Aeolus can write to a subdicrectory named »waves« in the stop directory. This is not the case in the stock installation. Thus I copied the stops to the home directory:

mkdir ~/.aeolus
cp -rf /usr/share/aeolus/stops/ ~/.aeolus

I did some further tweaks to the Aeolus installation, though quick and dirty. Last but not least I wrote a dirty script which is run by qjackctl after jackd is up and running. It automatically starts Aeolus with some parameters, and sets up the required audio and MIDI connections.

I’m running a owncloud server in the LAN which I use to transfer files between my machines. For the Raspi the main purpose is to share music scores and ogg respectively mp3 files of organ music. There’s an owncloud-client in the repository, but it’s rather barbed and not compatible with recent versions of the Owncloud server. Some tutorial to compile it manually didn’t work straightforward, so I stopped those efforts. Currently I’m mounting the file share via webdav. However, the sync is fast as snails, so I don’t recommend it. I hope to get the owncloud client compiled during the next weeks. Until then, a USB thumb drive will do…

After testing several PDF readers to display music scores, I got stuck with Okular. Left button clicks will switch to the next, RMB clicks to the previous page. The left button click can be done by touching the screen (great), but I wished there was some more intelligence, so as touching left and top would go to the previous, and right and buttom to the next page.

That’s it so far from my installation log file. It’s not a tutorial, and a lot of detail is missing. It’s just a reminder for the next time I’ll set one up.

First Jolla steps

Meanwhile I got a bit more used to Jolla’s user interface, and I’m quite curious how well it will serve me.

Of course I immediately started to configure the handset to my uses. Subsequently I shed some light on things I found surprising.

  • Operating System updates are available. The installation requires creating a Jolla account, though.
  • Creating the Jolla account requires passing rather detailed personal information, like a user name, real name, an e-mail address, a country, and even a birthday.
  • Several attempts to download apps or OS updates ended in endlessly looping progress indicators. A Reboot fixed this, though only once. Fortunately there’s a detailed tutorial how to make good use of the recovery mode
  • Connecting the device via USB requires the MTP protocol, which Mac OS X does not support. Copying files to the phone will thus require to insert a microSD card prefilled with the desired data. Hackers alternatively may want to use scp.
  • I managed at least to configure one (of four) owncloud calendars to appear in the phone’s calendar application. All dates appear shifted by an hour, though. Appearently time zones are ignored. The stock calendar application of Android allows to subscribe to multiple CalDAV calendars, and time zones never have been an issue.
  • I didn’t manage to configure CardDAV contacts via owncloud, and according to this (german language) posting, it doesn’t seem to be a problem at my end.
  • An attempt to import contacts from a VCF file caused the people application to be busy for quite some while (actually, unlike this posting, it’s not finished yet). I quit it and tried anew, which finally resulted in imported contacts within seconds. Unfortunately it didn’t import the contacts avatars, though this is a minor issue for my needs.
  • The owncloud news reader (I’m happy it exists!) requires online connectivity to mark messages as read. A notification that the synchronisation failed appears each message the user reads. The Android app is capable of buffering this information offline until the next sync.
  • A file manager is not available, unless the user activates the developer mode and uses the terminal application to activate the file manager. Unfortunately, the file manager shows a blank screen only. I uninstalled it via the shell, and installed the public domain File Browser via the Jolla Store.
  • A chess game is missing, ignoring the fact that GNU chess is available as a command line interface (aka CLI) application.
  • A media player is availabe via the Jolla Store. I was rather surprised that it immediately did show the mp3 as well as the ogg files of the microSD. It even showed album covers for ogg files, which are just jpg images placed in the folders containing the album’s ogg files. I’m happy :) .
  • The final pulse to go for a Jolla Phone was that someone ported MoNav for Sailfish and made it available via I copied some map data to the microSD. To make it available in MoNav, I enabled the developer mode to get access to the terminal application. Then I used vi ~/.config/MoNavClient.conf. I added a section named [MapPackages] and the key-value-pair path=/media/sdcard/6632-3036/MoNavMaps/. I hope the 6632-3036 is some static UUID for my sdcard and does not change during the next reboot.
  • I’m missing a chess game, ignoring the fact that GNU chess is available as a command line interface (aka CLI) application :) .

MoNav for Jolla respectively Sailfish OS

I just was notified that MoNav, a routing application for the Nokia N900 I helped to develop, is available for the Jolla phone respectively the Sailfish OS.

An installer is avilable via The source is hosted at Github. Some map material is available here.

I’m glad the code I wrote about three years ago is still of use for other people.

BTW: Some OwnCloud-Clients are available as well…

Automobiltechnik, die mich nicht begeistert

Kürzlich hatte ich für eine Fahrstrecke von rund 700 km über Stadtmobil einen VW Golf gebucht. Wenn man kein eigenes Fahrzeug unterhält, an das man sich gewöhnen kann, sondern immer wieder unterschiedliche Fahrzeuge nutzt, fällt es besonders auf, wenn man nicht intuitiv und spontan zurechtkommt.


Mein Telefon wollte ich mitnichten an die Bordelektronik koppeln – weder wollte ich telefonieren, noch wollte ich Musik hören. Unangenehmerweise hatte der Vorbucher selbiges genutzt. Das Fahrzeug suchte daher verzweifelt erst nach diversen Geräten von Vorbuchern (die ich persönlich nicht kenne) und anschließend nach einer Reihe von Standardgeräten. Die Anzeige zwischen Drehzahl- und Geschwindigkeitsmessgeräten liegt dummerweise ziemlich zentral, weshalb die ständigen Wechsel der Meldungen extrem vom Verkehrsgeschehen ablenken.

Somit ist man versucht, die Meldung loszuwerden. Das ist mir teilweise gelungen. Im Armaturenbrett findet sich eine große Schalkfläche, die mit “Phone” beschriftet ist. Nach einigem Herumgeklickere ist es mir zwar nicht gelungen, den Wagen davon zu überzeugen, sich überhaupt nicht für irgendwelche Telefone zu interessieren, aber immerhin habe ich es durch Abschalten der Bluetooth-Konnektivität geschafft, dass die Anzeige einen statischen statt einen dynamisch wechselnden Text anzeigt. Das ist doch schomma was.

Ich habe allerdings keine Ahnung, ob diese Anzeige jetzt die nächsten fünfzehn Lebensjahre des Fahrzeuges verbleiben wird. 15 Jahre, in denen sich der Bluetooth-Standard sicher ändern und diese Einrichtung voraussichtlich unbrauchbar machen wird.


Ich bin ein großer Freund des Tempomats. Er hilft Treibstoff und Knöllchen sparen. Da Tachometer qua gesetzlicher Anforderung eher vor- denn nachgehen, stellt man natürlich gerne etwas mehr ein als das Hinweisschild anzeigt. Statt 80 km/h also 85 und statt 100 km/h 108. Wobei diese Maßnahme der Drängelei der nachfolgenden Verkehrsteilnehmer keinen Abbruch tut, aber das nur am Rande.

In einem Golf kann die Einheit schonmal aus einigen nützlichen Steuerelementen am Lenkrad bestehen, die zusätzlichen Geber wie Gas- und Kupplungspedal nicht mitgerechnet. Im Lenkrad finden sich 7 (in Worten: sieben) Bedienelemente. Wobei die Plus- und Minustasten doppelt belegt sind und zudem unterschiedlich reagieren. Macht also schon 9. Die Lernkurve ist somit recht steil. Eine intuitive Bedienung ist nicht gegeben.

Besonders die Plus-Minus-Regler machen mir zu schaffen. Denn sie verhalten sich unterschiedlich. Kurzes Drücken regelt die Zielgeschwindigkeit in Zehnerschritten. Fein. Langes Drücken regelt die Zielgeschwindigkeit in Einerschritten. Auch fein. Gewöhnungsbedürftig ist, dass der Vorwärtsregler sich unterschiedlich verhält. Bei den Zehnerschritten wird zur Zielgeschwindigkeit hinzuaddiert. Fein. Bei den Einerschritten wird jedoch zur Momentangeschwindigkeit hinzuaddiert. Die zuvor in Zehnerschritten angepeilte Zielgeschwindigkeit springt also wieder komplett auf die Momentangeschwindigkeit zurück. Das überraschte mich.

Ferner regelt die Anlage nicht tatsächlich die Geschwindigkeit. Wenn ich auf der Landstraße mit 100 fahre und dreimal die Minustaste drücke, dann bremst ein Audi tatsächlich auf 70 km/h herunter. Sehr schön. Ein Golf mit 9 bzw. 11 Steuerelementen jedoch nicht. Insofern ist eines der Hauptnutzungsszenarien, nämlich das Vermeiden von Strafzetteln, nicht gegeben.


Kürzlich hatte ich den Firmenwagen zwecks Reifenwechsels in der Werkstatt. Die Gelegenheit war günstig, denn der Wagen erinnerte mich seit einigen Tagen bei jedem Einschalten der Zündung an den anstehenden Service, und die Frontschutzscheibe war durch einen Steinschlag lädiert.

Nach dem Abholen meldete der Wagen auf dem nächsten Weg zum Kunden einen Druckverlust. Ich habe also die Autobahn verlassen und den Druck geprüft. Alles in Ordnung eigentlich. Also neuen Termin vereinbart. Nicht ganz ohne Überheblichkeit bekam ich dann gezeigt, wie ich den derzeitigen Wert als Referenzwert im Wagenrechner hinterlegen kann. Hätte ich den Reifenwechsel selbst durchgeführt, wäre das sicher meine Aufgabe gewesen. Aber so? Naja…

Von der Lust, selbst ein Fahrzeug zu kaufen

Vorhin las ich in einer Nachrichtenmeldung, dass im Vergleich zu den 90er Jahren heute viel mehr Fahrzeuge von Firmen als von Privatpersonen zugelassen würden. Das wundert mich nicht. Die heutigen Fahrzeuge sind übersät mit Funktionen, Schaltern, Knöpfen und Displays, deren Bedienung mich schlicht und ergreifend nur nervt. Meinem Firmenwagen würde ich beispielsweise gerne abgewöhnen, das Radio bei jedem Starten automatisch einzuschalten. Trotz mehrmaligem Geklickere in den Fahrzeugmenüs habe ich es nicht hinbekommen. Das mag meiner Faulheit, das Wagenhandbuch zu lesen, geschuldet sein. In Zeiten von Smartphone und Apps möchte ich sowas jedoch ohne Lesen der Dokumentation hinbekommen können.

Ich habe das Gefühl, dass wir in der Softwareentwicklung trotz Smartphones noch immer einen weiten Weg vor uns haben, uns auf das Wesentliche zu konzentrieren und tatsächlich das zu schaffen, was wir gerne mit dem englischen Begriff »Value« zu umschreiben versuchen.

Ich bin dankbar darum, über Stadtmobil so viele verschiedene Fahrzeuge nutzen zu können. Keines davon überzeugt mich, und meine Lust, selbst eines zu kaufen, tendiert gegen null.