[Javier MM]

Javier MM - Are you seeing the text move that much while editing only when editing annotations that were created before the update? Or if you create a new text annotation, do you also see the text move like that? I'm definitely not seeing text jump like that on my device, so there must be a difference on your device that I'm not accounting for. It would be helpful if you can share a library backup file with me, or if that is not an option, long press your song on the library screen, tap Share->Export as .msf and send me the .msf. The .msf won't include your application settings, but I can at least try to edit your text annotations and see if I encounter the same behavior. If you are experiencing the text moving even with new annotations, then sharing the .msf isn't necessary as there is something else going on unrelated to existing annotations. 

As far as the size of the text not being consistent when you rotate into landscape...

Mike, I am seeing the same behavior with text moving regardless of the version I used to create the anotations. They move a lot or just some mm depending on the zoom I have when I edit. 

I can live with this. It is just that I have to remember not to use a zoom when I edit a text.

I have sent you a couple of scores with anotations. I am creating a library backup file that I may send you  with a wetransfer link if this helps.

Regarding the size, I am not sure of understanding everything. I think the way it is now is perfect.

When I write a new anotation I want it to be as big as the existing ones. To do so, I usually check the size in a mode (portrait) and make my anotations also in the same portrait mode. 

You can have some funny results if you check the size of an existing anotation in portrait (size 15) and then create a new one (size 15) in landscape mode. But this is not the usual workflow.

I agree with you it makes more sense to be consistent and increase the size of the image and the anotations together, as it is with this new version.

[Zubersoft]

I'll see if I can reproduce any issues with text annotations while zoomed in. 

As far as the sizing, I think the main thing I'm worried about is a scenario like this: You have a file at a lower resolution, say 300x200, and the tablet screen is 1200x800 (just to make the math easier). So the file will be increased in size by 400% to fit the screen. If all tool settings are relative to the raw PDF page size (300x200 in this case), a size 20 highlighter would be 20 pixels high in that file, which would show up as 80 pixels tall on the screen. If you then opened a file that is 600x400, and used the same highlighter, it would show up as 40 pixels tall on the screen because the file was only increased in size by 200%. Both files looked like they were the same size on the screen, but due to one file being lower resolution, the highlighter will appear to be a very different size than when used on the higher resolution file. I can only see this confusing users who may not realize that the resolution of the images in the files would play such a big part in how the annotation sizes will be determined. I just don't see how I can support both having the tools be a consistent size with different resolution files, but also be sized correctly regardless of how the page is scaled when the annotation is created. I really need to hear more feedback from users to know how they expect things to behave and which one is more important - having the tool sizes be consistent regardless of image size/resolution, or ensuring that annotations created with a certain size tool will be consistent with other annotations created with that same size regardless of the page scaling/tablet orientation, even if it means that the tool settings will potentially look different with every file that is used.

One thing I could do (although it will add some complexity in determining how to calculate sizes for annotations), is to give the user the ability to control whether the tool sizes are based on the screen resolution or the file resolution. If the sizes are based on the screen resolution, then you would have consistent tool sizes regardless of resolution, which makes it easy to use the same tool settings for all files. If the sizes are based on the file resolution, then you can zoom in/out as needed before annotating, rotate the tablet, etc, and the annotations will all be sized the same regardless of the page scaling. You just may then run into issues with inconsistent tool sizes when switching between files with different image resolutions. For users that like to rotate their tablet a lot and change the zoom level outside the annotation mode, basing the tool sizes on the file resolution would be a better option, especially if they ensure that their files all use images of identical or similar resolutions.

Thanks,
Mike

[palosanto]

Mike, Javier
I haven't been following very closely the problem with the text annotations because I don't really use text very often.
But I was trying it earlier and I thought  would share my findings. When I type a text annotation a couple of odd things happen when zoomed in:

This seems to apply to both of my devices as far as I can tell:

When I'm zoomed out 100%:

The first tap brings the keyboard up and shows the cursor ready to type, exactly where I tapped.
If necessary the screen will shift up to accommodate the keyboard if the chosen location is low enough to require it so that the keyboard doesn't cover it. This is normal.
So everything works as it should. 

While zoomed in:

What seems to happen: The first tap displays the keyboard and the cursor along with some recent text annotations seem to either shift up a lot or disappear altogether and I can't see what I'm typing. Then when I tap on the screen to finish, the keyboard disappears and the new text shows up along with the other annotations that had disappeared.

What actually happens is that the cursor and recent text annotations have moved up either off screen or up on the screen along with the whole score shift trying to accommodate the keyboard and they are not obvious to see as they are so far away.
I think that MSP calculations for shifting the screen up to accommodate the keyboard are not correct when zoomed in so the screen moves up even when it wouldn't need to when I'm choosing a text location high enough in the screen to require a shift.  So it ends up off screen or way higher that expected.

Mike, I have the feeling that you are scaling also the restricted area covered by the keyboard so when you are zoomed in and type on a location that wouldn't normally be covered, it thinks that is bigger and causes the shift even though it's not really needed because the keyboard would have fit perfectly. 
And the shift seems to increase the more you are zoomed in.

I hope I'm making sense ...

[palosanto]

I'll see if I can reproduce any issues with text annotations while zoomed in. 

As far as the sizing, I think the main thing I'm worried about is a scenario like this: You have a file at a lower resolution, say 300x200, and the tablet screen is 1200x800 (just to make the math easier). So the file will be increased in size by 400% to fit the screen. If all tool settings are relative to the raw PDF page size (300x200 in this case), a size 20 highlighter would be 20 pixels high in that file, which would show up as 80 pixels tall on the screen. If you then opened a file that is 600x400, and used the same highlighter, it would show up as 40 pixels tall on the screen because the file was only increased in size by 200%. Both files looked like they were the same size on the screen, but due to one file being lower resolution, the highlighter will appear to be a very different size than when used on the higher resolution file. I can only see this confusing users who may not realize that the resolution of the images in the files would play such a big part in how the annotation sizes will be determined. I just don't see how I can support both having the tools be a consistent size with different resolution files, but also be sized correctly regardless of how the page is scaled when the annotation is created. I really need to hear more feedback from users to know how they expect things to behave and which one is more important - having the tool sizes be consistent regardless of image size/resolution, or ensuring that annotations created with a certain size tool will be consistent with other annotations created with that same size regardless of the page scaling/tablet orientation, even if it means that the tool settings will potentially look different with every file that is used.

One thing I could do (although it will add some complexity in determining how to calculate sizes for annotations), is to give the user the ability to control whether the tool sizes are based on the screen resolution or the file resolution. If the sizes are based on the screen resolution, then you would have consistent tool sizes regardless of resolution, which makes it easy to use the same tool settings for all files. If the sizes are based on the file resolution, then you can zoom in/out as needed before annotating, rotate the tablet, etc, and the annotations will all be sized the same regardless of the page scaling. You just may then run into issues with inconsistent tool sizes when switching between files with different image resolutions. For users that like to rotate their tablet a lot and change the zoom level outside the annotation mode, basing the tool sizes on the file resolution would be a better option, especially if they ensure that their files all use images of identical or similar resolutions.

Thanks,
Mike

As far as I'm concerned the method that you are using now creates the most problems of inconsistency in screen size working in one file when creating new text, shape outlines, free form, stamps, etc at different zoom levels with the same selected tool size. We discussed exactly that recently.
So the alternate method (explained in your quotation in your above post #164) would make more sense to me even if the tool sizes display differently in different files unless you can figure out a way to save the tool sizes along with each file for the next time that I open that file or adjust automatically the last tool sizes used when opening a new score in function of its different resolution even the internal size becomes different that the previous one.
You mentioned that the raw pdf internal registered size would be different but the nominal size could be the same across files?  Or do I have all this mixed up?  
Again in any case my vote is for consistency in display while creating new content at different zoom levels or rotating screens at least within the same file.
Juan

[Zubersoft]

If you go to the display options in the song overlay at the bottom left, and then Zoom/Pan Settings and disable high-quality zooming, then you can zoom in and out as much as you want it and you will not encounter the problems with the annotation sizes being inconsistent. The reason is that, if you disable high-quality zooming, the zooming is the same whether you are in the annotations mode or outside of it, so the tools will scale properly. The high-quality zoom re-renders the file at a different size (which causes the UI element containing the rendered image to be a larger size), and that new size is treated as the 100% zoom. While you pinch zoom and the page size is changing rapidly, it's always doing a "low-quality" zoom where it is just instructing the canvas (i.e. 2d rendering engine) to scale whatever it is rendering up or down as needed. When you release, it then requests a high-quality zoom of the page, which generates a new image that is put in place of the low-quality one shown on the screen. The low quality zoom is much faster than a high-quality zoom, as it's just an instruction to the 2d rendering engine versus having to call into the PDF libraries to generate a new image from the page with a different desired scaling. If you zoom in and out a lot and don't really need the high-quality zooming, I would suggest turning it off, as MobileSheets is designed in such a way that it expects users to zoom their files to a desired amount and then not change that zoom again (so that the song is ready for a live performance where you wouldn't want to be adjusting the zoom amount). 

I'm really not sure what the best answer is for handling this, because in solving one set of issues for some users, I'm creating a new set of issues for other users. For users that aren't zooming or rotating their devices in between annotation sessions, it's far worse to have the annotation tool sizes inconsistent with every file they annotate, as they won't know why their size 15 text annotation looks completely different from one file to the next.

I'll check out the issues with editing text while zoomed in - thanks.

Mike

[palosanto]

If you go to the display options in the song overlay at the bottom left, and then Zoom/Pan Settings and disable high-quality zooming, then you can zoom in and out as much as you want it and you will not encounter the problems with the annotation sizes being inconsistent. The reason is that, if you disable high-quality zooming, the zooming is the same whether you are in the annotations mode or outside of it, so the tools will scale properly.

Wow, that's a big discovery for me... all the problems with size when creating annotations while zoomed or not go away.  Yeah, sure they don't look as sharp while you are annotating zoomed in but neither the pdf itself, they are images. So the way I see it it's faster and  usually one doesn't stay zoomed in after annotating but zooms 100% and carry on playing ...
I always had HQ zoom on but you never mentioned that difference in behavior when I was reporting what I though it was a bug. So basically there's nothing to fix then?
Sorry I'll stop now ... I think I'm getting a headache, hahaha

[Zubersoft]

There is still an issue if you rotate your tablet between landscape and portrait, as this will scale the page by a different amount, so the annotation sizes will be inconsistent when created in each orientation. So it's a partial workaround, but if you don't rotate your device, then it should fix all of the problems you are encountering right now.

I'm going to have to give this some thought going forward. I may still consider giving users the option for deciding how tool sizes are handled, but the difficulty is in explaining this properly in a concise way that won't confuse users. 

Thanks,
Mike

[palosanto]

There is still an issue if you rotate your tablet between landscape and portrait, as this will scale the page by a different amount, so the annotation sizes will be inconsistent when created in each orientation. So it's a partial workaround, but if you don't rotate your device, then it should fix all of the problems you are encountering right now.

I'm going to have to give this some thought going forward. I may still consider giving users the option for deciding how tool sizes are handled, but the difficulty is in explaining this properly in a concise way that won't confuse users. 

Thanks,
Mike

I can see that. Only when rotating ... so I guess this scaling is different that zooming of course.
Thanks,
Juan

[McAroni]

Javier MM could you try the following: in the file where the text shifts to the side while editing bring up the overlay and tap the 4th icon on the bottom. (scale mode) cycle through all the scale modes (fit to page, half page, ect...) go back to your preferred scale mode and try editing the text again. I saw the shift on my Samsung and after I have done this the inserting and editing of the text was fine. Maybe this helps. 

Thank you for your help. I have tried various scaling modes and the text still moves around when I edit. 

I found another file where the text input was off.... Try again the cycling through the scale modes, and after that reset the crop of the file. Then everything was fine again.

[Harry777]

Another thing that's been driving me crazy...

Can you make it so that when "don't allow the pedal to go to the next piece" is set on, that the pedal can't go to the previous pieces either? Or make it a separate option?

So often I'll mash the pedal to get to the beginning and accidentally go to the previous piece ?

Thanks!

[jeffn1]

Another thing that's been driving me crazy...

Can you make it so that when "don't allow the pedal to go to the next piece" is set on, that the pedal can't go to the previous pieces either? Or make it a separate option?

So often I'll mash the pedal to get to the beginning and accidentally go to the previous piece ?

Thanks!

Hello, Harry,

I was actually the person that asked Mike to add the option of pedals not triggering going to the next song. At the time, I used pedal triggers ("mash down the pedal") to move multiple pages, including back to the beginning of the song.

I resisted using the "page links" for a long time.

But, I figured I would chime in that I started using them and I would never go back. They are much better than (work flawlessly, once you figure them out) than holding down the pedal to go back to the beginning of a song.

So, I just figure iI would suggest that maybe you play around with the page links option. (although your suggestion does make total sense too)).

Jeff

[August]

Wanneer komt er een versie voor iOS of Apple.wacht al sinds 2019.

[Harry777]

Another thing that's been driving me crazy...

Can you make it so that when "don't allow the pedal to go to the next piece" is set on, that the pedal can't go to the previous pieces either? Or make it a separate option?

So often I'll mash the pedal to get to the beginning and accidentally go to the previous piece ?

Thanks!

Hello, Harry,

I was actually the person that asked Mike to add the option of pedals not triggering going to the next song. At the time, I used pedal triggers ("mash down the pedal") to move multiple pages, including back to the beginning of the song.

I resisted using the "page links" for a long time.

But, I figured I would chime in that I started using them and I would never go back. They are much better than (work flawlessly, once you figure them out) than holding down the pedal to go back to the beginning of a song.

So, I just figure iI would suggest that maybe you play around with the page links option. (although your suggestion does make total sense too)).

Jeff

Thanks for the suggestion, Jeff!

I'm definitely going to try link points in the future. Unfortunately for me, since I play the double bass, getting up to tap the screen quickly isn't much of an option for me. I could definitely see it being useful for D.S./D.C.s if there's a a lot of resting, though!

As far as connecting multiple pieces together, are you suggesting I link the last page of one song to the first of another so that I can easily jump back and forth?

I actually saw in the manual that you can set a custom page order, which would probably work best for me with my foot pedal.

If only my instrument gave me some more flexibility!

[McAroni]

If you have a pedal, the Link Points could be activated by it. Just use "Go to next Link point or next page" in the pedal settings. There is no need to Touch the screen

[jeffn1]

If you have a pedal, the Link Points could be activated by it. Just use "Go to next Link point or next page" in the pedal settings. There is no need to Touch the screen

Yes, that's what makes them so useful. I trigger them via foot pedal.

As long as you always play the song/chart the same way (with Codas, etc.), link points triggered by your foot pedal are great.

Jeff