I am trying to get PianoBooster running on the PengPod 10" Tablet, which would be ideal to put onto my Yamaha EZ-220 keyboard.
The program compiles just fine on the supplied Linaro image (well, almost, I had to add -lGL to the linker manually), but unfortunately the QGLWidget that should display the score stays entirely black.
After two days of researching, I was told on #qt that OpenGL/ES (which the PengPod uses) does no longer support the gl*List commands.
Similiar, this probably goes for glBegin and glEnd from what I've read elsewhere, though don't remember the source.
This would explain, of course, why the window stays black and nothing is printed, when the qtdemos work just fine, although with little fps (3-5).
I have then started trying to move all the drawing code from OpenGL to a QPainter, but my knowledge of OpenGL is limited, my knowledge of Qt is basically drawn from the API documentation and I don't understand a lot of what goes on inside pianobooster.
I have uploaded my efforts so far on github at https://github.com/blind-coder/pianobooster-nogl if someone dares to take a look :-)
Do any of you have a suggestion on how to best continue from here? I'd really like to use pianobooster with my keyboard, but putting a laptop into the scoreholder is just silly :-)
Kind regards and thanks for a great piece of software,
Thanks for telling me about your ambitious port of PB to the PengPod 10" Tablet.
When I started the PB project i thought it would be easy to get the notes scrolling sideways -- a sort of guitar hero game on it side. however I hit a lot of problems with side ways scrolling with flickering and tearing of the score which makes trying to READING the notes on the screen uncomfortable. (It also explains the reversed green colour to try and use the persistence of the eye and using a single colour helps with slow LCD displays) To get something smooth enough to read comfortably I needed a frame rate faster than the LCD refresh rate of 60 hz. So I tried to offload _everything_ to the graphics processor and leave virtually no drawing every 20 msec frame. so the only thing that is drawn every cycle is the NEW notes that are added to the screen on the right hand side and they are chained to all the other notes in the GPU using the gl*List command. I carefully choose the the OpenGL/ES standard which is a subset of full GL programming and is suited to embed devices. So i don't understand why they have dropped gl*List commands.
Trying to untangle the GL code to use QPainter would be extremely difficult in my opinion and probably not worth the effort.
I am _extremely_ busy at the moment and have got not any spare time to devote to this. but I have not been so happy with sideways scrolling but I was thinking that it might be better to use a regular display like used on http://midisheetmusic.sourceforge.net/. (does that compile on your PengPod 10" Tablet?) Maybe as a longer term project it might be worth merging the pb engine with the midiseetmusic display. PB would need a lot of refactoring and code tidy up (including adding threading) before it is worth starting on any merging of the two code bases, something at the moment that I haven't got any spare time to do so. but let me know if you would be interested to help with if ever I start on this idea.
I finally got it up and running!
The main problem was that the Mesa libraries were compiled without support for "generic" OpenGL, so the glBegin and glVertex* functions were replaced with empty code blocks. Using a SuSE image providing these functions draws everything on the screen.
This brings me to the one and only, true "bug" in PianoBooster:
In one point you are using a "char" to pass a signed integer to a function. "char" is a signed integer on x86 architectures, but is an unsigned integer on ARM. Changing this to a int8_t makes PianoBooster work like a charm :-)
No, unfortunately this has nothing to do with an Android port.
I simply tried another distribution and found it had support for OpenGL and then noticed that some notes like a c seemed to be displayed as c''''''''' (way above the bars).
Having had a char-on-arm bug a few weeks ago I checked if that was the same here and succeeded.