• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Automatic Scrolling: Per Page Settings
#1
Before I start my post, I want to say thank you for making this app - a couple of years ago I was considering coding an Android sheet music app myself but MoblieSheets is so good already it would be a waste of time if I did now. Also, thanks for making the free version fully featured - I've tried it for a while now and will almost certainly buy the Pro version (probably when I buy a new tablet especially for sheet music / MobileSheets). Smile

My feature request is simple: Automatic Scrolling works well when the pages have similar amounts of music on them, but this is not always the case - please could you implement per-page settings for automatic scrolling? There can still be a default for the overall song, but if certain pages have more/less music (or duration of music) on them then it would be great if this could be considered in the automatic scrolling. Ideally you would be able set the number of bars and tempo for each page to make it near-perfect, but even a % of the standard page duration for the song would work.

If this already exists and I missed it in the manual, then sorry! Shy
Reply
#2
Bought the Pro version today. Smile

Does no one else have the issue with automatic scrolling where there is a different amount of music on each page / tempo variation throughout the piece?
If so, how do you solve this (except maybe by buying a foot pedal or similar to do the page turning manually)?
Reply
#3
The problem with anything 'automatic' is that there is always one or more cases where the algorithm used doesn't quite match what is actually required.

I think this is the reason so many of us go for some sort of manual control - it lets us stay in charge Wink .

USB pedals are cheap, Bluetooth can be a lot more expensive (but see http://zubersoft.com/mobilesheets/forum/...p?tid=2254 for something in-between in cost, should you need to go wireless).
Graeme

1: Samsung 12.2" SM-P900: Android 5.0.2 
2: eSTAR GRAND HD Quad-Core 4G 10.2": Android 5.1 


Some of my music here - https://www.soundclick.com/graemejaye
Reply
#4
(07-12-2015, 02:06 AM)GraemeJ Wrote: The problem with anything 'automatic' is that there is always one or more cases where the algorithm used doesn't quite match what is actually required.

I think this is the reason so many of us go for some sort of manual control - it lets us stay in charge Wink .  

USB pedals are cheap, Bluetooth can be a lot more expensive (but see http://zubersoft.com/mobilesheets/forum/...p?tid=2254 for something in-between in cost, should you need to go wireless).

Thanks for the link - I'll have a look. Smile

I still think per-page automatic scrolling settings would be a very useful (and not overly difficult) feature to implement. There is already per-page customisation (e.g. annotations/cropping) so it would just be an additional variable there and a check in the automatic scrolling to see if the current page has an overridden automatic scroll setting.
Reply
#5
Sometimes things that seem simple on the surface turn out not to be very simple at all. In the case of providing automatic scroll settings per page, the UI changes wouldn't be too bad, but I would have to restructure all of the database tables to hold a list of automatic scroll settings per page instead of just one set of settings for a song. This would change a fair amount of code by itself. Then I would have to update the automatic scrolling code to be able to automatically switch settings every time a page is turned, which might not be too bad, but things might get a little weird if it's automatically scrolling and you manually turn the page and it has to adjust the settings dynamically in the middle of a scroll.

I'm not even sure that this completely solves the issue though, because, based upon feedback I've gotten, in order for the automatic scrolling to really handle all scenarios, it would need to be very programmable. You'd need to be able to specify how fast to scroll on each section and automatically handle repeats. The tempo may change in the middle of a page, so one setting for a page really isn't even enough to handle that. Having said all that, I'm not sure if the right answer is to keep trying to extend the current automatic scrolling to handle all these cases, or to break it out and have a simple automatic scrolling feature for basic users (as it is now) as well as a more powerful automatic scrolling feature that is extremely configurable but requires more setup beforehand for power users. Of course, to support this kind of advanced automatic scrolling, I would not only have to design a brand new editor that could handle all of the new features, but also redesign the automatic scrolling code.

I'm open to feedback on what people think would be the best direction for the future.

Mike
Reply
#6
I'm a big proponent of auto scroll as I feel it is basic to music display. In this case though I think 2 versions is preferable if adopted, with the advanced version being worked on in the future as time/interest [yours] permit. The only advantage I can see to a highly programmable version is it could eliminate the need for one piece of hardware, a page turner, over the current version. A high programming capability can also be considered a time consuming one and may not be worthwhile to most/many users.
Dell Latitude 13.5" 2-in-1 Ubuntu/Win 11
Samsung Note Pro SM-P900 12.2 Android 5.0.2
Samsung S7+, Android 12
Reply
#7
(07-12-2015, 04:49 AM)Zuberman Wrote: Sometimes things that seem simple on the surface turn out not to be very simple at all. In the case of providing automatic scroll settings per page, the UI changes wouldn't be too bad, but I would have to restructure all of the database tables to hold a list of automatic scroll settings per page instead of just one set of settings for a song.  This would change a fair amount of code by itself. Then I would have to update the automatic scrolling code to be able to automatically switch settings every time a page is turned, which might not be too bad, but things might get a little weird if it's automatically scrolling and you manually turn the page and it has to adjust the settings dynamically in the middle of a scroll.

I'm not even sure that this completely solves the issue though, because, based upon feedback I've gotten, in order for the automatic scrolling to really handle all scenarios, it would need to be very programmable. You'd need to be able to specify how fast to scroll on each section and automatically handle repeats.  The tempo may change in the middle of a page, so one setting for a page really isn't even enough to handle that.  Having said all that, I'm not sure if the right answer is to keep trying to extend the current automatic scrolling to handle all these cases, or to break it out and have a simple automatic scrolling feature for basic users (as it is now) as well as a more powerful automatic scrolling feature that is extremely configurable but requires more setup beforehand for power users.  Of course, to support this kind of advanced automatic scrolling, I would not only have to design a brand new editor that could handle all of the new features, but also redesign the automatic scrolling code.

I'm open to feedback on what people think would be the best direction for the future.

Mike

Thanks for responding on this. I can see how one speed per page might not work if there are multiple tempos on the same page, but at worst if you had it at the average you should hopefully have the relevant section on the screen (though maybe not perfectly at the top) at all times and be in the right place by the end of the page. As for repeats being at different tempos, since I use vertical scrolling I tend to repeat the page/section so it is in the file twice (and hence could have different speeds for automatic scrolling if there was a per-page setting). If you had per-page scroll settings, most complexities could probably be worked around by duplicating the page in this way and cropping to the relevant sections. Of course you probably don't want to do this if you're using a different display/scroll setting, but it makes sense for vertical scrolling display and automatic scrolling.

Perhaps another solution altogether could be an automated page turner instead of automated scrolling - where you would enter the commands (i.e. switch to page 2, switch to page 3, switch to 75% down page 1, etc.) and set up the time through the piece where these should be executed. Of course this would be a whole new feature so probably even more code required than the automated scrolling enhancement.
Reply
#8
(07-12-2015, 05:38 AM)alex_hk90 Wrote: Perhaps another solution altogether could be an automated page turner instead of automated scrolling - where you would enter the commands (i.e. switch to page 2, switch to page 3, switch to 75% down page 1, etc.) and set up the time through the piece where these should be executed. Of course this would be a whole new feature so probably even more code required than the automated scrolling enhancement.

I think that capability is already there. Look at automatic scroll settings>scroll behavior and it's modifiers.
Dell Latitude 13.5" 2-in-1 Ubuntu/Win 11
Samsung Note Pro SM-P900 12.2 Android 5.0.2
Samsung S7+, Android 12
Reply
#9
(07-12-2015, 05:45 AM)Skip Wrote:
(07-12-2015, 05:38 AM)alex_hk90 Wrote: Perhaps another solution altogether could be an automated page turner instead of automated scrolling - where you would enter the commands (i.e. switch to page 2, switch to page 3, switch to 75% down page 1, etc.) and set up the time through the piece where these should be executed. Of course this would be a whole new feature so probably even more code required than the automated scrolling enhancement.

I think that capability is already there. Look at automatic scroll settings>scroll behavior and it's modifiers.

I can't find it if it is; I can only see "Scroll and Pause", "Scroll and Pause After Page Turn" and "Scroll Continuously To End".
What I'm talking about by "automated page turner" would be something where you could enter how long before each Scroll event, and vary this.
For example: after 5 seconds show page 2, after 4 seconds show page 3, after 3 seconds show second half of page 1, etc.
Whereas "automated scrolling" would be like the current capability, which always scrolls forward rather than turning between the pages (sometimes going back if there are repeats, etc.).
Reply
#10
I think the very complexity of what has been said so far merely goes to support my view that manual control is, by far, the most flexible approach.

My recommendation to Mike would be to leave it as it is - seems to suit the broadest range of users.
Graeme

1: Samsung 12.2" SM-P900: Android 5.0.2 
2: eSTAR GRAND HD Quad-Core 4G 10.2": Android 5.1 


Some of my music here - https://www.soundclick.com/graemejaye
Reply
#11
Mike;
I set up a 6 page pdf, portrait mode, to 'single page mode' with the scroll setting 'scroll continuously to end', 5 second pause duration, medium speed. My question is, can the pause duration be coded, without a heavy penalty, to enable it to be applied to each separate page, ie., page 1 at 5 sec, page 2 at 12 sec, page 3 sec, etc? Could it be split into 6 separate pages then run sequentially in a set list with the above configuration?
Dell Latitude 13.5" 2-in-1 Ubuntu/Win 11
Samsung Note Pro SM-P900 12.2 Android 5.0.2
Samsung S7+, Android 12
Reply
#12
(07-12-2015, 09:34 AM)GraemeJ Wrote: I think the very complexity of what has been said so far merely goes to support my view that manual control is, by far, the most flexible approach.

My recommendation to Mike would be to leave it as it is - seems to suit the broadest range of users.

Agreed that manual control is the most flexible approach, but that would still be available if the automatic scrolling feature was enhanced. Smile
Personally I would prefer to use automated scrolling for a piece if I had it set up and only switch to manual if something changes (i.e. repeating a section, tempo variable, etc.) or if I hadn't pre-programmed the automated scrolling options.
Reply
#13
It's nearly as much work to provide a pause duration per page as to just redesign all of the settings to be per page, as I would still have to make all the database changes and UI changes for that field, so if I'm going to change, I might as well make all of the settings configurable per page. I'll add this to list of future enhancements. I'll probably put a toggle at the top of the dialog that indicates whether the settings are being applied to the whole song or per page. This would make it a little easier to change the behavior as needed. Otherwise I could see it being confusing for some users if they wanted to change the setting for all pages and it only modified it for one.

Mike
Reply
#14
(07-13-2015, 02:46 PM)Zuberman Wrote: It's nearly as much work to provide a pause duration per page as to just redesign all of the settings to be per page, as I would still have to make all the database changes and UI changes for that field, so if I'm going to change, I might as well make all of the settings configurable per page. I'll add this to list of future enhancements. I'll probably put a toggle at the top of the dialog that indicates whether the settings are being applied to the whole song or per page. This would make it a little easier to change the behavior as needed. Otherwise I could see it being confusing for some users if they wanted to change the setting for all pages and it only modified it for one.

Mike

Thanks Mike. Smile
Reply
#15
Thanks for clearing that up Mike.
Dell Latitude 13.5" 2-in-1 Ubuntu/Win 11
Samsung Note Pro SM-P900 12.2 Android 5.0.2
Samsung S7+, Android 12
Reply




Users browsing this thread:
2 Guest(s)


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2024 MyBB Group.