tendays wrote:Two things:
1. I wrote a program once that would listen to my playing, compare it to a pre-recorded version so that it can turn the page at the right time. It's quite rough so far (command line interface on linux only (it interfaces with any scriptable document viewer)) but works for me (And now I got a full-time job, so not much time left to develop it further).
http://pageturner.sf.net if anyone's interested
I find that far more convenient than having to use a special pedal to turn the page as I am used to be ready to use the piano pedals at any time. I'd have to move my foot aside then move it back, which is distracting if the page turn occurs at a difficult place. I might even sometimes miss the page-turning pedal and have to look down to find it if moved away etc (disclaimer, I never actually tried that). OTOH I'm using my laptop screen as display which is not convenient. I have been thinking about getting a kind of tablet so I can put it on my piano music stand.
Thanks for sharing! I looked over your sourceforge page and watched the video; very cool (nice Schubert, btw). An automatic, touchless page-turning feature is something that a lot of people have suggested and that we're considering, though it may or may not be a priority for the first public version. I can see your point about the pedal potentially being distracting for pianists. I've always imagined that I would just use my left foot for the page turn and keep my right foot free for the piano pedals, but more testing is in order to see how comfortable that would be. Also, I realize that some pianists may need both feet for pedals, though I rarely use pedals other than the sustain, myself. Would definitely be an issue for organists, though.
tendays wrote:2. About displaying page turns, a way which sounds good to me, better than sudden page changes, better than scrolling, is to gradually reveal the top of the new page over the top of the old page while the bottom of the old page is still available at the bottom of the display. So if page 1 has rows ABCDE and page 2 has rows FGHIJ you'd transition from the first to the second by displaying FBCDE, FGCDE, FGHDE, etc, probably with a moving horizontal line between the two so it is clear which bits are from page 1 and which bits are from page 2 — that way the player can decide when to start looking at the next page and yet know the previous page is still there if needed, so things stay where they are on the screen until they disappear. (Also, please, no silly and distracting page-turning animations.)
Good luck with your project!
I like this; it's a little bit similar to MusicReader's "half page"-at-a-time option for page turning, though that's somewhat of a misnomer. Basically, say you have pages of sheet music A, B, C, D, etc. Normally, in two-page view, you would see A-B, then paging forward would reveal C-D. If you change the setting to "half page," you see A-B, then paging forward reveals C-B, then C-D, E-D, E-F, etc. So you can always still see the most recent page every time you page forward.
Your second suggestion, combined with the first, would actually overcome my main objection to automatic page-turning, which is that I read ahead several bars, and how far ahead is unpredictable -- depends on the music, how long I've been practicing it, and a host of other factors. A sudden automatic page turn like the one in your video would make me nervous because the program couldn't know the *precise* split second I need the page to turn, and in fast music this could be a big problem. With a gradual/half-page transition, though, the precise timing would be less important. However, I would still need to trust that the program really is following along intelligently -- what if I mess up and my playing doesn't exactly match the pre-recorded version? What if I take a repeat that the program isn't expecting, or omit one? Can it handle transpositions, embellishments, and improvisations? These are all things we'd need to consider in deciding whether to pursue this as a feature.
And we'll keep your comment about animations in mind.

Thanks again for your suggestions.
-----------------------------------------------------------------------------
mosc wrote:I have some comments. None at your product specifically but at the strengths and weaknesses in the concept.
1) The best use case for this tech is for music groups that use both hands and read from a score. Handbell ensemble, percussion ensemble, and piano music. The score means fewer measures. A key similarity in all these cases is the inability to turn pages with your hands. This means that having a "next page" button on the screen is not a substantial improvement. Better would be a foot triggered device.
Thanks for the comment! We are indeed planning to include a foot pedal option.
mosc wrote:2) Annotations in a word doc or PDF file are simply not going to cut it for a good musician. They take too much time to enter and take up too much real estate. I can't imagine a half-way decent system for handling this. Due to this, I would consider marketing the product with a scanner turning the music stand into a "performance" music stand. It's not particularly useful for practice. My personal squiggles are very different and an evolution how how I learned music. They're not going to be in an OTS product.
3) due to points 1 and 2, the touchscreen part is rather useless. A foot activator and a scanner would be better additions than being able to touch the music.
The idea is that the touchscreen would allow you to draw directly on the digital sheet music the way you would on paper. The most recent iteration of development discussions has us leaning toward an IR screen, because it would allow you to use anything as a stylus, or no stylus at all. But again, don't quote me on this.
We're definitely making ease-of-annotation a big development priority; we know that they're extremely important to many musicians and are often quite personal and organic. Thanks again for your comments!