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").Įxperience shows that it might be wise to have more pedals: "start/stop autoscroll", "one page back", "back to last link point", "back to top". 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. But this is a task not easily met "just now" by a relative new-comer to MSP. 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. Large repetition jumps or quite confusing "cross-country" jumps in the sheets led to complete disorientation. For pieces with just short repetitions the sheets were manageable for me. ![]() 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. In any case, thanks for considering to support my request! In that case the interference with the pedal would make absolutely no sense. 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. 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. Quote: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. And my suggestion is going into that direction. But exactly in these situations it is very helpful not to have to be very precise but flexible. to incorporate new, less experienced members in our playing group, or to speed up a so far known piece. And we tend to play our pieces with varying velocity, e.g. 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. 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!īut 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. ![]() 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. ![]() 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). 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. 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. 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. That is why the software stops the automatic scrolling in this case. 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. 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. 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 used to allow the pedal to be used in combination with automatic scrolling, but it actually caused very negative behavior in some situtations. ![]() I can look into trying to support this in a future update.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |