In the prior two installments I described the process involved in developing a piano Sheet Music reader. In this installment, I give some details of the programming to date as of this writing.

Having tried client/server and javascript already, I decided I wanted a more classic (ok, I would say “real” but do not want to offend the javascript zealots) language and framework. It needed to also integrate with one of the two PDF libraries I could find: MuPDF and Poppler.

MuPDF had a reputation for being faster, so I tried it first. I decided to go with the more conventional path of C and GTK+. I had never used GTK+ and my C skills date to the time of bell bottoms, but …

Short version: Failure. If I built MuPDF from source, it had conflicting library routine names with GTK+, and I could find no straightforward solution (perhaps my limited skills). In particular oft used items like calloc just did not work.  So I installed all from an available ubuntu distribution, and hit other roadblocks – it required routines (jpg library routines in particular) which had incompatible build options. Researching this lead to the suggestion: Build it from source.  Full circle.  Stop.  I am sure this will be resolved; it looks like changes in multiple projects that are now incompatible, and someone will fix it.  Probably soon. But I decided to move on.

Poppler is a more stable variation, and it had wrappers built for multiple platforms. Among them was QT. My brief foray into GTK+ went fine, but it seemed… old.  It was quite usable, but I thought I would change.

QT is an interesting product. I had never used it, but heard of it. It is one of those hybrid open source projects that you see more of – for some usages it is free (in the “free beer” as well as “free speach” sense), in other cases it is not open at all. The supporting company makes money off of the latter but still supports the former. In this case, the basic expectation (I say that as opposed to license) is that you also make your project open source, and then you can use the product for free.

It also is VERY much a multi-platform product, with support across a variety of classic and embedded devices. So if I want to change from the Pi, or others want to use this on another platform, it is already there. (Though who can give up the name “Musical Pi” to run on a compute stick – I mean “Musical Stick” just is not the same).

So some research –

• Can I build QT on regular Linxu (Ubuntu) to use for development – Yes.  Worked fine.
• Can I build QT on the Pi – yes.  Worked fine also.  Though the instructions for this are very confusing, as you can configure it to work in a variety of graphics environments, basically the normal X11 or directly to the frame buffer.
• It uses C++; ok, my experience there is more recent, not the Bell Bottom era at least. And I like it a lot more than classic C.
• Licenses OK?  Well, who the heck knows. If there is a more confusing, and misleading description of licensing, it would be hard to find. Here is their FAQ.   That is fairly clear, except for what it does NOT speak to – it describes (more or less) what you get if you package QT into your distribution. What if you just use a already distributed version of the library and call it, do you need to follow these rules?   Who knows; blog articles have been written far and wide on how and when you need to buy the commercial version.
• But… did I care?   No, because I intended to make my code open source and available anyway, so I decided the complicated licensing of QT (and every change rules, as each version shifts open source license types lately, it seems, and indeed parts are with different licenses than others, leaving (in combination) a mess).  So basically “I do not care”.
• Is it fast?  Sure, it runs compiled code, and uses GTK+ and/or other libraries underneath the covers, so it does not appear slower (both in research and in some brief tests).
• Did I like the QTCreator IDE?  It was OK.  A bit like eclipse, but simpler, and hangs together a bit better.
• And finally — there were pre-build versions (a bit old, 5.5 vs. 5.7) available as both Ubuntu standard distributions, and the Pi Ubuntu version. So I did not need to build it, and more importantly (since I already did once) people who want to use the code do not need to also build Qt orPopper.

So… off to start writing code.

Having written this once in Javascript, I had some idea of what I needed:

• The ability to read the Calibre library (which is SQLite so that is pretty straightforward)
• Some settings (eventually – for now hard coded as constants in a header)
• A Music display for review – a way to page through lots of pages to find where you might want to start, to see if this is the right arrangement, etc.
• A “Play” mode, which de-clutters the display, and allows for page turns in a convenient fashion.
• Annotations – if you want to mark up your music

Annotations are hard; that will come later if I get it working, so I worked on all the rest.

QT is basically a set of C++ wrappers for graphics and some other functions. There are multiple generations of it.  The older basic version is widgets.  Later they developed “Quick” features, the QLM language, designers for animations and the like. I decided (partly based on being at 5.5) to stick to classic widgets, believing that it would also run faster on wimpy Pi hardware.  Also, I believe in knowing how things work under the covers; 4GL’ish GUI designers provide very quick design, but also a disconnect.

So the project is based on QT Widgets, basically a main page and a lot of widgets that are hidden and exposed based on the mode you are in.  They are also created on the fly for PDF pages both cached and visible.

I also did not do cross compilation for the Pi.  I did the development on a regular Ubuntu on Inten, running in HyperV.  This makes it several times as fast as a Pi (even the new ones) and is much more pleasant for development.  I used Xming as a Windows X11 client, and let the Ubuntu display on my windows machine.

When I have a working version for the Pi, I move the source and build it there as well (not through QT Creator, just a QMake and Make), and run that native version.  QTCreator is designed so I could do cross compiles on Intel for the Pi, but so far I have not.  No good reason, just that this was easy and the documentation for cross compiling for the Pi is heavily confused by different Pi Linux flavors and versions.

So I have a usable development environment, my pedal and screen and Pi are here. Of to write some code.

(Lots of time passes here as I lean QT widgets and C++).

In the next installment I will discuss using it – kind of a spec for the development, kind of a user manual.