I have been trying to find a scrolling setting for Portrait mode on the 2 monitors I use most. One for home, and one for elsewhere.
I am using the song Homeward Bound as my test music. It has 9 pages (3 verses), in the sequence 1-3,1-3,1-3, and each page is cropped to the smallest reasonable top and bottom margins to only show that part of the song required at that time. On my old 1280x1024 monitor in Portrait mode takes 2 minutes 55 seconds overall, which is perfectly timed for the music. On my Laptop 2000x3000 screen in Portrait mode it takes 4 minutes 55. Which is a vast difference!
The settings I have been experimenting with are:-
Page Scaling - Portrait Fit Width
Display Mode - Portrait Vertical Scrolling
Automatic Scrolling Settings - Scroll Continuously to End
Fixed Duration - 1.6
Time before Scrolling Starts - 6
Is there any way of using the settings in Mobile Sheets to get the time taken to scroll the full length song to be constant regardless of screen resolution - at least in Portrait mode.
I have also been using a blank "box" to cover unwanted sections of the score where repeats occur. I note that these move around depending on screen resolution too. It would be perfect if the scrolling time and comments/stamps etc remained fixed too regardless of screen resolution.
Is it possible to use the screen resolution/window size metric to modify the scroll rate so it is constant between screen sizes? This would also make the settings portable between Windows Android devices.
Any suggestions would be most welcome!
Cheers
John in Sunny Carnarvon - Western Australia
If you use one of the scroll speed settings between slowest and fastest, they will scale their scrolling speed based upon the screen size. While your devices have different aspect ratios and resolutions, you should get pretty close results if you choose that approach. If you choose a fixed duration for the scrolling time, you will most likely get different results on each monitor as I don't scale that scrolling speed based upon the monitor size. Based upon your selection of 1.6, that would indicate that the entire height of the screen should be scrolled every 24 seconds. The orientation you use on each device and the relative size of each page on the screen will impact how long it will take to scroll through the entire song.
One potential option for a future update would be to specify the total number of seconds to use to scroll the entire song, but what this could result is the scrolling speed on each device appearing very different (as one device may have larger pages and thus more pixels to scroll through). If you prefer having that kind of option, I can certainly look into adding it.
If you are using a square annotation with a white fill for the background, that should not be moving around on the score if you are using a PDF. It should be saved relative to the raw PDF coordinates so when you load the song on a different device, it will scale to match the amount the PDF is scaled on that device. If this is not working, it would help to have a screenshot of each device so I can see how much the annotation is off from where it should be.
04-04-2018, 07:41 PM (This post was last modified: 04-04-2018, 07:44 PM by JBlyth.)
(04-04-2018, 04:09 PM)Zuberman Wrote: If you are using a square annotation with a white fill for the background, that should not be moving around on the score if you are using a PDF. It should be saved relative to the raw PDF coordinates so when you load the song on a different device, it will scale to match the amount the PDF is scaled on that device. If this is not working, it would help to have a screenshot of each device so I can see how much the annotation is off from where it should be.
Mike
Hi Mike,
Here is a screen shot.... What All I did to create the problem was to drag MobileSheets across my four monitors to check how the scrolling worked with different resolutions on my WINDOWS 10 laptop. Oh, and time the scrolling from start to finish of the song on each monitor.
The original box was were the red circle is. I can select the text box as you can see, but I can't move it anymore to relocate it back to its original position, either with the arrows or by dragging the box. I get an error message when I try and delete it of "You cannot delete the only group". However, I can edit it! This is the same for the other similar text boxes I have created in this song.
For scrolling, I will try the Slowest-Fastest method again and see if I can get it fine tuned enough for each song. I personally would like the option to see an overall time after the "Initial Time before Scrolling Starts". A change in the visual scrolling speed won't worry me on different devices or screens as long as it tracks through the song at the same speed that I play it. If this is possible, then scrolling across different monitor and Android devices will be constant, which is ideal if you have to change devices urgently for some reason....
However, what is easy to say can be very difficult to implement and write, I know. I'm happy to assist in any way if required.
I tried using the scrolling speeds Fast and Faster rather than duration, but the first was too slow, and the second was too fast....
With fixed duration I can be more precise with the scrolling speed, but of course then I run into the problem (for me at least) of having the actual song scrolling duration change depending on screen size/resolution.
So an overall time to scroll the length of the entire song would be very useful for me.
Cheers
John
Please try using a square rectangle with the pen drawing tool to blank out the content instead of using a textbox. I think that may scale properly between the two devices. I will have to look into the text issue to see if I can reproduce that.
04-05-2018, 10:30 AM (This post was last modified: 04-05-2018, 11:00 AM by JBlyth.)
(04-05-2018, 12:48 AM)Zuberman Wrote: Please try using a square rectangle with the pen drawing tool to blank out the content instead of using a textbox. I think that may scale properly between the two devices. I will have to look into the text issue to see if I can reproduce that.
Mike
Hi Mike,
I tried your suggestion with the Pen Tool, which is much more convenient to use for blanking out sections of music, but I found that they disappeared altogether when moved to a different monitor - see attached pics.
[EDIT] I just restarted MS and now the Pen boxes are ok on the second monitor but not the first - ie a reversal of the attached images... [EDIT]
Of interest, I was able to delete the original text boxes when I moved MS back to the "original" monitor I created them on. Very weird.....
I am very happy to test anything you might suggest
Are both monitors connected to the same device? I move MobileSheets between my monitors all the time but I don't think I've seen that problem happen. I'll have to run some tests to see if that occurs for me. Due to the fact that the annotations are not embedded in the files themselves and that I have to store information about the annotations relative to the screen they were created on, it can be a lot more difficult to ensure proper scaling between every screen size, resolution and density. Annotations definitely should not be disappearing or moving large distances though - that definitely indicates a problem of some kind.
1) On my PC, I imported a file, and drew a white box on it. I then backed up my library. My main PC has multiple monitors and the primary one is 3440x1440.
2) On my little test device, which has a 10.1 screen with 1280x800 resolution, I restored the backup.
3) On the test device, I loaded the song and verified that the white box is in the exact location it should be.
4) On my PC, I dragged the MobileSheets window between my monitors and the white box always stayed in the same location and looked fine
So I'm not seeing the problem you are seeing and will need instructions for exactly how to reproduce the problem. I'm not sure if something is different about your test environment or the types of files you are using. For reference, are you using PDFs or image files?
04-05-2018, 06:04 PM (This post was last modified: 04-05-2018, 06:31 PM by JBlyth.)
[quote pid='21096' dateline='1522904049']
Hi Mike,
SOME GREAT NEWS FOR YOU!!!!!!
Much further below are the results of the tests I did, BUT, I have found what causes the problem with the boxes moving. It seems to happen when MS is opened, a song is selected, and then the program IS DRAGGED TO ANOTHER SCREEN.
If a song is NOT selected first, then dragging MS to another screen causes no problems with the boxes AT ALL. Was that a big sigh of relief I just heard Perhaps if you could re-sample the apparent screen size/resolution when opening each song, you might be able to mitigate this issue????
On the subject of Scrolling the above "trick" doesn't fix the changing scrolling times, I'm afraid. I also tried the metronome timing method, but that seems to be effected by screen size too, so a variable fixed delay at the start of a song plus a timed scroll to the end would be very useful to me. I guess as more people start using the Windows 10 version and change monitors from time to time, the issue may become more pressing. It will be a pain to have to re-time the scrolling for every song whenever a user wishes to use a different device or screen size - for me at least ;-)
HOWEVER, I have discovered than when using the settings in the previous post for scrolling (with Page width set as the sizing), that if I size the width of the MS widow very carefully so I get about 20% more of the song showing before the scrolling starts, then the scrolling time is "adjustable". Does this imply that a check of the program's width could be a controlling factor in preserving the scrolling duration between different screens? I also tried running the program in a window on the bigger monitor sized with Display Fusion to 1280x1024, and the scrolling still ran considerably slower than required - about half speed)
I have also noticed on occasion that the scrolling speed suddenly slows down markedly near the end of a song, It seems to happen with this particular song every time, but I have noticed it to varying degrees with others.
Cheers - an apologies for this being so long!
John
This is still worth a read.... ================================
I am running version 2.1.3. It updated this morning. All my music files are PDFs.
I am using a Surface Book 2 laptop with a native screen resolution of 3000x2000
My preferred screen for MS is an old Sony LCD of 1280x1024 running in Portrait (Flipped) mode running via a Targus Dock
My second test monitor is 2560x1440 running via a Moshi HDMI adapter
I have an additional TV 1360x768 running HDMI from the same Targus Dock
I have just done the following test...
Opened MS on the laptop screen and dragged it to the Sony LCD 1280x1024
Pressed F11 to put MS in full screen mode
Opened up a three page PDF of Walk Away Renee - no cropping of any pages as yet
Created a Pen box on page two of the PDF
Dragged MS to 2560x1440 monitor sized to left half of screen to get MS into portrait mode - box has shifted down and to the right
Restored MS to the full size on the 2560x1440 monitor - white square has moved as in 5.
Dragged MS to Laptop Screen - White rectangle not seen on any page
Restored MS to the full size of the 1360x768 monitor - white square has NOT MOVED AT ALL.
I then shutdown MS and repeated steps 4 - 8, and I got exactly the same result. Just to confirm, this is all using my Surface Book 2 as a device, and moving MS between the monitors specified.
I also tried creating a box starting on the 2560x1440 monitor, and moving MS across monitors. In each case the boxes moved out of position.
It is interesting that the two lower resolution monitors appear unaffected (even though one is in portrait and the other is in Landscape), while the two "better" monitors have significant differences. I cannot explain it....
Very happy to test further if I can help (rather than hinder). You can use TeamViewer to look at my system if you wish.
Windows has a setting under Display for "Change the size of text, apps, and other items". This scaling factor can play havoc with code that requires specific pixel locations. So throughout most of the code, I have to scale values by the scaling factor windows is using to get the actual number of pixels (so that things work properly on other devices that may have a different scaling factor). If you start MobileSheetsPro on one monitor, it's going to save the scaling factor of that monitor. If you then drag it to another monitor that has a different scaling factor, it's probably not going to compensate well for that, as it's not being properly notified of the change in the scaling factor of the monitor. I'm going to test that right now, but I'm guessing that's what the problem is. I thought I had added code awhile back to check for changes in the scaling factor in Windows 10, but that may only work if the user changes the scaling factor in the Windows 10 settings. Dragging between monitors with different scaling factors probably doesn't result in any kind of notification for the app. I'll have to see how to properly handle that.
I have a bug fix in place now for switching between monitors with different scaling sizes in the Windows 10 settings. It definitely was an issue, so thanks for bringing it to my attention.
No, those changes won't impact the scrolling speed change issue. I'll have to spend some time testing myself to see if there are some flaws in the logic that can be addressed, or whether the new option I described (scrolling the entire song by a fixed time) is the appropriate answer.
Perhaps if you could re-sample the apparent screen size/resolution when opening each song, you might be able to mitigate this issue????