[Petra-Kathi]

Hello @all,

I didn't find a related topic, therefore this new thread.

As far as I understand the manual and did some own testing, you have to decide whether to auto-scroll a set of score sheets or to scroll pages "manually" e.g. by a foot pedal. If you hit the foot pedal during auto-scrolling the scrolling stops and you have to deal with the advances yourself from then.

Another PDF viewer with musicians' support has a different approach: You set an autoscroll value and the score is advanced accordingly. But you can scroll back/forward also by the set amounts of manual scrolling, without stopping the auto-scrolling by doing so.

I consider this as a definite pro feature: it is very difficult do set the auto-scroll to the correct value in advance, so for pieces with 4+ sheets it is highly desirable to have the possibility of adjusting the momentary position without leaving the auto-scrolling mode by doing that.

This relates to the Android version 2.6.2

Cheers,
Petra

[Zubersoft]

Petra,

I can look into trying to support this in a future update. I used to allow the pedal to be used in combination with automatic scrolling, but it actually caused very negative behavior in some situtations. The way automatic scrolling is designed, it basically recalculates the amount to scroll for page (depending upon how much of the page is shown) and then performs a scroll over time for that amount of pixels. I'm relying on the Android framework to recalculate the layout for the pages on the screen each time a UI update occurs, and my software calculates the amount to offset each page based upon how much time has occurred since the last layout was triggered. So the scrolling is not something that can be interrupted and restarted with ease because if the pedal shifted the page, and potentially changed the page, all of the parameters for the automatic scrolling have now changed and all of the calculations that were performed are now invalid. That is why the software stops the automatic scrolling in this case. What I can look into doing in the future is to add one more step - after the automatic scrolling is stopped, the pedal initiates the scroll and the scroll animation has completed, then I could invoke the automatic scrolling again (which would recalculate the amount to scroll) but it would skip the pause before starting. If "Scroll entire score in fixed duration" is the current setting, then this gets more complicated as I have to save how much time had elapsed during the last automatic scroll, and then recalculate the speed at which to scroll the remaining pages in order to finish in that amount of time. The reason I haven't attempted to adjust any of this behavior is because I really want to avoid messing up anything with the automatic scrolling, as users spend hours and hours adjusting all their automatic scrolling settings to get things perfect for their performances. Any small change I make can mess up those settings if I'm not careful (which I have done in the past and people were VERY angry). So I have to ensure that any change I make does not change the behavior of the scrolling in any way that would cause those users settings to no longer be correct.

Thanks,
Mike

[Petra-Kathi]

Hi Mike,

thanks a lot for this thoughtful and thorough explanation! I can very well imagine your efforts not to interfere with done work of other people that use your app long since!

But the very fact that it took them so long to set up the timings shows me that the basic approach - to depend on the precise pre-emptive setting of a song - might somehow be sub-optimal. I should add that I am just a hobby player who tries, now and then, new pieces thrown into the ring from fellow hobby musicians in small living room formations. And we tend to play our pieces with varying velocity, e.g. to incorporate new, less experienced members in our playing group, or to speed up a so far known piece. But exactly in these situations it is very helpful not to have to be very precise but flexible. And my suggestion is going into that direction.

What I can look into doing in the future is to add one more step - after the automatic scrolling is stopped, the pedal initiates the scroll and the scroll animation has completed, then I could invoke the automatic scrolling again (which would recalculate the amount to scroll) but it would skip the pause before starting.

This would completely satisfy my requirements! With a full score page of "time padding" some tenths of a second do not break the flexibility-oriented approach.

Your concern about "Scroll entire score in fixed duration" is certainly valid, but if this setting is chosen you might, with a very good reason, rule out the option of intermediate pedal using, IMHO. In that case the interference with the pedal would make absolutely no sense.

In any case, thanks for considering to support my request!

Cheers,
Petra

[Skip]

FWIW, I set up vertical scrolling and scroll continuously to the end, then set the speed a bit faster than I expect to play. When in use I start and stop the scroll. If I need to go back or jump to someplace in the middle, I use link points. One pedal is set to 'start/stop scroll', the other 'turn page or go to next link point'. I also set the start scroll to 0.

[Petra-Kathi]

Hi Skip,

this is an interesting approach, indeed! Only applicable to strictly linear pieces, though, IMHO. And you must make sure that you always start out too fast as you can only toggle stop/start of scrolling. But I like the idea that you only have to concentrate on one pedal for most of the time.

If you could use auto-scroll and pedals quasi-simultaneously as suggested in my initial posting, my method would be usable for smaller in-between repetitions as well, without have to fuss around with pre-emptive page ordering and sectioning. And you wouldn't have to make sure to stay ahead with your scrolling since you can adjust in both directions.

Thanks for sharing your idea!
Petra

[Petra-Kathi]

I tested Skip's suggestion yesterday: I set the two pedals to "scroll back or turn page" and "start/stop auto-scroll", and it worked - mostly. For pieces with just short repetitions the sheets were manageable for me. Large repetition jumps or quite confusing "cross-country" jumps in the sheets led to complete disorientation. It seems clear now that such pieces need pro-active preparation by page ordering and section cutting to get a clean march through the sheets. But this is a task not easily met "just now" by a relative new-comer to MSP. But I just didn't know in advance which pieces we would play, and my list is too long to have all set in an anticipatory manner.

I found it interesting to see the coping experience which seems to be better for the chosen pedal setting compared to the former test one ("deliberate manual scroll up", "deliberate manual scroll down"). 

Experience shows that it might be wise to have more pedals: "start/stop autoscroll", "one page back", "back to last link point", "back to top". With presumably the middle ones to be unified.

Anyway, thanks for the idea of pedal setting!

Petra

[Petra-Kathi]

I'd like to revisit this older thread based upon my recent experiences with tablet score reading.

I had set my two pedals to "start/stop scrolling" and "page back", and it works so far. But my recent observations:

# Setting a scroll speed to play with a "human" player group (in opposition to playing with a computer) is difficult and subject to change.
# The "page back" pedal can fully be replaced by a manual interaction, at least in all my uses so far

What I am missing after all is:

# Increase (moderately) the scroll speed without stopping the actually happening scrolling

The reasoning:

If the scrolling is (a bit) too fast (i.e.: my reading point slowly moves up on the screen), I can always give it a break with the scrolling toggle pedal. But if I run out of lines below (i.e.: scrolling is too slow) there is no means to readjust the scroll without a manual interaction. The only means offered so far would be: Set 2nd pedal to advance the score a portion of, say, 70% of the screen height. But this leads quite certainly to a loss of focus of the point that is to be read on the sheet, and it will need a double interaction: Jump and restart scrolling - which is quite distracting, IMHO.

As the scroll timing mismatch perception (you continuously tend to look to either always deeper or higher places on the tablet) is a rather slow one if the original scroll speed is not set completely wrong the use of such a speed increase functionality is not a stressy one, so I could typically choose a less difficult reading situation to invoke it.

Mike did mention further up that he could implement some adjustment function without breaking the presently implemented time-keeping functionality for those not in need of it. Therefore I'd love to see this feature (moderately increase scroll speed by a pedal action without stopping the ongoing scroll) implemented.

What do you think, Mike?

Cheers,
Petra

[Zubersoft]

The way scrolling works at the moment is that the application scrolls in chunks, and a chunk could be either an entire page or a portion of a page. For each chunk, the application figures out how long it will take to scroll the required number of pixels with the current scroll speed, and then sends the scroll command over to the display adapter which actually moves the music on the page. The automatic scrolling controller then waits until the display adapter says it's done scrolling the requested amount. So the problem is that, if adjustments are made to the scrolling speed with a pedal in the middle of the scroll, I can't easily adjust both the display adapter and the controller at the same time as all of the calculations were based on the initial number of pixels to scroll and the scroll speed at that time. So I think the way this will need to work is the scrolling will have to be stopped and then immediately restarted with a new scroll speed. This would obviously skip all the normal delays when scrolling is started. I will have to test to see how smooth this is if the scroll speed is adjusted multiple times in a row.

Mike

[Petra-Kathi]

Hi Mike,

thanks for the thorough analysis of the process! Just for me to understand it a bit better: Is the chunk size you write about the part of the page one can set by the scroll value as percentage of the screen?

OTOH, you may start/stop scrolling the score by a pedal as well, even if you pre-defined a fixed duration for the complete song. Accordingly I'd consider a deliberate(!) change in scroll speed as something quite similar to that. Nobody *has* to use this function if not required/desired.

As the (vertical) scrolling itself is comparably slow I don't think users will regard it as a problem if the scroll stops shortly and restarts with the desired change in speed very shortly after. I'd expect this restart process to be well in the sub-second regime?

Thanks for actively searching for a solution!

Petra

[Zubersoft]

If the scroll behavior is set to "scroll and pause", then yes, the chunk would be the percentage chosen by the user. If the scroll mode was "Scroll continuously to end of song" or "Scroll entire song in fixed time", each chunk is a full page I believe (or however much is required to scroll the next page to the top of the screen). 

Starting/stopping should happen well under a second in normal operation. The application does need to wait for the scroll cancellation to fully finish before restarting, but that shouldn't take very long. It's all about how responsive the UI is in the Windows 10 version, as I'm not too worried about the Android version. The switches I'm going to make to the rendering in the Windows 10 version for the annotations rework should help with this as well (as I'm switching to Direct2D).

Mike