In the prior installment I gave some feeling for the the thought process of building a Music Reader for my piano. Here is my first attempt.
My next issue was to pick a software platform – language of course but more importantly how would the display connect to the hardware, decode PDF’s, etc.
pdf.js is an open source project that morphed into the PDF display program for Firefox. The source is available, and modifiable, but because it runs as a native part of Firefox it is also well maintained by Mozilla and others.
I won’t spend a huge amount of words on this, as I decided to move on from this project, but it was educational. I had not programmed for Windows in a while (living more in the linux world), so was delighted to find that Visual Studio was now itself free (at least in a somewhat limited version), but annoyed to find that Asp.net had become Asp.core, but buckled down and decided to acclimate.
Never dive into Microsoft as an early adopter (for that matter maybe any platform). Microsoft went from closed and poorly documented, to open and “document it yourself if you want to know how it works”. The documentation became, basically, Google, and while it was evolving rapidly in lots of blogs, the product was evolving even faster. This meant most tutorials were obsolete even if a month old, API’s had changed (if you could call some of them even an “API”), and even syntax was changing as fast as I could learn it.
But I got it working. An Asp.Core project on Windows accessed the library, let you chose songs, and passed off the PDF to pdf.js in a browser window to display.
And it worked.
So (I am thinking), do I really want to keep enhancing this one? I decide “no”.
It did let me learn a lot.
Another, as mentioned, was I simply did not like asp.core as it existed now – I knew I would be spending the next year adjusting for changes in the framework to keep it running. Not really terrible (and it would be educational), but annoying.
And… did I want to touch the screen to turn the page? Or did I want a pedal. I was finding many (most? all?) of the commercial products had some kind of pedal. Especially since I wanted this to be user friendly for my wife, I decided to get one. In this case I decided NOT to build one, though I could see a number of ways to do so (including usurping the almost unused middle pedal of the piano), but just ponied up the money to buy a well known one.
After a lot of reading I chose the PageFlip Firefly.
It was expensive ($109 at the time from Amazon), but it supported both regular batteries, USB power, USB communication and Bluetooth communication (which the Pi has natively now as well), and several different codes it can send to indicate a page change. Ordered it, and it seems perfect; easy to set up (put in batteries and lay on the floor), paired on first try, and works nicely. Nothing but good things to say about it, well, other than — both my wife and I tend to touch the screen. Old habits die hard. So if you want a pedal (actually two — don’t forget you need to go backwards at times) I recommend it; but you might find touching the screen is OK also and save the money.
Finally, the more I thought about it, the idea of doing the back end on Windows (i.e. the Windows software not just as a database repository) and the front end in Linux somewhat defeated the purpose. So I decided to look for a better framework and scrap this project.
I also experimented with various distributions on the Pi, various web browsers, and the keyboard. Turns out it is not exactly easy to get a virtual keyboard in Linux that works uniformly. Some that are embedded in certain distros just did not work well. I settled on the Mate version of Ubuntu for Pi, and OnBoard as the keyboard. But more on the details of that later.
That said… it worked. If anyone wants a copy to experiment with, drop me a line, I can try putting it up on github (it is not there as of this writing).
And on to another platform choice and round two of software implementation.