Pixmap in translucent QLabel overlay, distorts screen

[anda_skoa]

I unfortunately was not saving backups as I wrote the code (shame on me -- it was on a VM so wasn't part of the normal backup)

Off topic but that's why git is such a tremendously nice tool even for just local usag

Cheers,
_

[Linwood]

It's on the list to learn. Sometimes the list should be in a different order.

[d_stranz]

The gods of code sometimes work in very mysterious ways. It isn't the first time something that didn't work suddenly started working (or more often, the other way around), and "I didn't touch anything in that module!"

Onward and upward.

As for your rendering, I am hard pressed to believe that you would have trouble rendering the next page of a score while the current one is being viewed, but maybe this is a Prokofiev or Liszt piano concerto or something with more ink than white space on the page. I don't know if you are rendering from a source like MusicXML or MIDI, but presumably you can process these in a piecewise fashion? If so, you can run your rendering code and at each stage, break out to call QCoreApplication::processEvents().


There's a good article by Wysota here.

[Linwood]

Oh, I changed LOTS of things. It's no mystery that something fixed it, I just don't know what.

As to rendering aspect -- the normal playing aspect is fine. There's nearly infinite amount of time (relative to what's needed) between one page and the next while playing forward.

However, there are other modes:

1) Select a song, and want to start -- it's annoying (if not significant) to wait 4 seconds before the first two pages appear, but...

2) I have a mode with 4 x 2 pages shown for browsing, e.g. looking for a specific spot in a large score. Those render a bit faster, but not fast enough - now I have maybe 10-12 seconds to render all 8 pages to get the first display or the next if I immediately hit "next".

The second is far more serious, and is probably the main reason I need to cache and have multi-threading, so when I first load up, I can pretty quickly get well ahead of the pages that might be displayed if they go into that mode.

I think the longest song I have is 12 pages, but in reading about other people who have done this, they describe music 300 pages long. I don't know that anyone other than me will ever use this, but I ought to try to make it useful if so in those cases, so I need a sliding window of cached pages that can go pretty quickly.

There's also:

3) going back. This is a bit easier if I have a cache as it should already be there but is a good example of where you don't have a lot of time. Music sometimes repeats, and the repeat-from may be anywhere from a few bars back from your current spot on the same page, to several pages back. You want to get back to that page quickly when you hit the repeat point, as there may be no available transition (transitions are a whole different matter because you want the new page displayed before you really quite finish the current -- going forward that's easy, not so easy going back).

Handling those transitions, like putting up half a page at times, is what I was working on that "fixed" the overlay I had.

Now I'm working on cache management and multi-threading, so who knows what I'll break ... or fix. I think I've conceptually got what I need, and good isolation, but haven't gotten enough written to even hit Build yet.

[d_stranz]

Sounds like rendering pages into a cache using rendering thread(s) might be the best option. You might also consider non-real-time rendering - a separate program or mode to render a score into a permanent cache, from which you can then pull page images at play time.

I've seen several classical and jazz pianists (Keith Jarrett for one) playing from a tablet instead of a paper score, so it's a growing trend. A 300 page score is something the conductor might use for a full-length symphony or opera, but I think I'd have a hard time (as a conductor) working from a tablet. It would be too small to see.

[Linwood]

My own implementation is with a 21" flat screen monitor that sits on a piano. That makes most music displayed approximately life sized two up, like a book, so it feels rather nice. Mostly I did this for my wife who is learning, and has these big massive books that will not stay open, plus I find it very nice.

I'm tying it to Calibre on my desktop (which is always up), and using Calibre as a library of music. That gives me some pre-built advantages, plus I already use it for eBooks. My goal was to keep nothing permanently on the Pi, so if I (for example) mark up a page with annotations, I planned to shove it somehow back in Calibre as an annotated version. In principle this is then usable on any device with network connectivity to a "server".

If I can ever learn enough about Qt to actually FINISH it. The threading version is mostly working now, though I have some issues with cleaning up QImage references passed between. Back to work...