Since 2009, I am persuing a personal programming project.
As I am not a professional programmer, I have spent quite a lot of that
time exploring options. I have thrown out about three or four prototype
implementations already. My last implementation seems to contain enough
accumulated wisdom to be actually useful. I am far from finished, but the path
I am walking now seems relatively sound.
So, what is this project about? I have set myself a rather ambitious
goal: I am trying to implement a two-way bridge between visual music notation
and
braille music code. It is called
BMC (Braille Music Compiler).
My problem: I am, as some of you might remember, 100% blind.
So I am trying to write a translator between something I will never
see directly, and its counterpart representation in a tactile encoding
I had to learn from scratch to be able to work on this project.
Braille music code is probably the most cryptic thing I have
ever tried to learn. It basically is a method to represent
a 2-dimensional structure like staff-notation as a
stream of characters encoded in 6-dot braille.
As the goal above states, I am ultimately trying to implement a converter
that works both ways. One of my prototypes already implemented
reading digital staff notation (
MusicXML) and transcribing
it to Braille. However, to be able to actually understand all the concepts
involved, I ended up starting from the other end of the spectrum with
my new implementation: parsing braille music code and emitting
digital staff notation (
LilyPond and MusicXML). This is a rather unique
feature, since while there is commercial (and very expensive) software out there
to convert MusicXML to braille music code, there is, as far as I know,
no system that allows to input un-annotated braille music code and
have it automatically converted to sighted music notation.
So the current state of things is, that we are able to read certain
braille music code formats, and output either reformatted (to new line-width)
braille music code, LilyPond or MusicXML.
The ultimate goal is to also implement a MusicXML reader, and convert
the data to something that can be output as braille music code.
While the initial description might not sound very hard, there
are a lot of complications arising from how braille music code works,
which make this quite a programming challenge. For one, braille music note and
rest values are ambigious. A braille music note or rest that looks like
a whole can mean a whole or 16th. A braille music note or rest that looks like
a half can mean a half or a 32nd. And so on. So each braille music code value
can have two meanings. The actual value can be caluclated with a recursive
algorithm that I have worked out from scratch over the years. The original
implementation was inspired by Samuel Thibault (thanks!) and has since then
evolved into something that does what we need, while trying to do that very
fast. Most input documents can be processed in almost no time, however,
time signatures with a value > 1 (such as 12/8) tend to make the number of
possible choices exploed quite heavily. I have found so far one piece from
J.S. Bach (
BWV988 Variation 3) which takes about 1.5s on my 3GHz AMD (and the
code is already using several CPU cores).
Additionally, braille music code supports a form of "micro"-repetitions
which are not present in visual staff notation which effectively allow certain
musical patterns to be compressed if represented in braille.
Another algorithmically interesting part of BMC that I have started
to taclke just recently is the linebreaking problem. Braille music code has
some peculiar rules when it comes to breaking a measure of
musical material into several lines. I ended up adapting
Donald E. Knuth's algorithm from
Breaking Paragraphs into Lines for
fixed-width text. In other words, I am ignoring the stretch/shrink
factors, while making use of different penalty values to find the perfect
solution for the problem of breaking a paragraph of braille music code into
several lines.
One thing that I have learnt from my perivous prototype (which was apparently
useful enough to already acquire some users) is that it is not enough to just
transcribe one format to another. I ultimately want to store meta information
about the braille that is presented to the user such that I can implement
interactive querying and editing features. Braille music code is complicated,
and one of the original motivations to work on software to deal with it was to
ease the learning curve. A user of BMC should be able to ask the system for a
description of a character at a certain position. The user interface (not
implemented yet) should allow to play a certain note interactively, or play the
measure under the cursor, or play the whole document, and if possible, have the
cursor scroll along while playback plays notes. These features are not
implemented in BMC yet, but they have been impleemnted in the previous prototype
and their usefulness is apparent. Also, when viewing a MusicXML document in
braille music code, certain non-structural changes like adding/removing
fingering annotations should be possible while preserving unhandled features of
the original MusicXML document.
This also has been implemented in the previous prototype, and is a goal
for BMC.
I need your help
The reason why I am explaining all of this here is that I need your help
for this project to succeed. Helping the blind to more easily work with
traditional music notation is a worthwhile goal to persue. There is no free
system around that really tries to adhere to the braille music code standard,
and aims to cover converting both ways. I have reached a level of conformance
that surpasses every implementation of the same problem that I have seen so far
on the net.
However, the primary audience of this software is going to be using Windows.
We desperately need a port to that OS, and a user interface resembling NotePad
with a lot fewer menu entires. We also need a GTK interface that does the same
thing on Linux. wxWindows is unfortunately out of question, since it does not
provide the same level of Accessibility on all the platforms it supports.
Ideally, we'd also have a Cocoa interface for OS X.
I am afraid there is no platform independent GUI framework that offers
the same level of Accessibility on all supported platforms. And since much of
our audience is going to rely on working Accessibility, it looks like we
need to implement
three user interfaces to achieve this goal :-(.
I also desperately need code reviews and inspiration from fellow programmers.
BMC is a
C++11 project heavily making use of
Boost. If you are into one
of these things, please give it a whirl, and emit pull requests, no matter
how small they are. While I have learnt a lot in the last years, I am sure
there are many places that could use some fresh winds of thought by people that
are not me. I am suffering from what I call "the lone coder syndrome".
I also need (technical) writers to help me complete the
pieces of documentation
that are already lying around. I have started to write a
braille music tutorial
based on the underlying capabilities of BMC. In other words, the tutorial
includes examples which are being typeset in braille and staff notation, using
LilyPond as a rendering engine. However, something like a user manual is
missing, basically, because the user interface is missing. BMC is currently
"just" a command-line tool (well enough for me) that transcribes input files to
STDOUT. This is very good for testing the backend, which is all that has been
important to me in the last years.
However, BMC has reached a stage now where its functionality is likely useful
enough to be exposed to users. While I try to improve things steadily as I can,
I realize that I really need to put out this call for help to make any useful
progress in a foreseeable time.
If you think it is a worthwhile goal to help the blind to more easily
work with music notation, and also enable communication between
blind and sighted musicians in
both ways, please take the time
and consider how you could help this project to advance. My email address
can be found on
my GitHub page. Oh, and while you are over at GitHub,
make sure to star BMC if you think it is a nice project.
It would be nice if we could produce a end-user oriented release
before the end of this year.
Not very interesting, since all of the logic is currently in the main binary and not on library code. But 1) when I do the refactorings I want to, there will be more library code and 2) while writing this I implemented also parsing scripts in 
An even larger (but still not that big) project, gem2deb:
Note that these visualizations may not be accurate representations of the actual source code. In Ruby, nothing stops one from implementing class 
Jo and I just got back from our massive holiday in Australia. We
had an awesome time overall, fitting in lots of stuff
in 4 weeks. Time for a quick write-up and some photos!
Several improvements have been made to UDD s 
We re now 
Like 
Thanks to our sponsors
The new sponsors of the month are in bold.
I'm using 
