[mjlarocque]

Hi!

I have started using the half page display mode, and it is really wonderful!  I had a nice surprise when I scrolled to small pages (i.e. cropped to only a small portion of the page to go to a DS, Coda, etc.).  The one thing I find difficult to manage, though, is that when the pages I scroll to are small enough to show up together, MobileSheetsPro has the smart to show them right away as a single page, kind of.  However, it does not keep the position of the half page already displayed, which makes it hard to follow when reading quickly.

Not sure I am making myself clear.  Let's say I have made my song into 5 pages to handle a DS with a coda.  The DS target is at the bottom of true page 1, the "go to coda" is at the top of page 2, and my coda is at the bottom of page 2.  I have made my page sequencing 1,2,1,2,2, and cutoff the pages to only show the relevant portion - so my new page 3 only shows from DS and on, my new page 4 shows only up to "go to coda", and my page 5 only shows the actual coda.

When I scroll from page 1, I see the top of page 2.  Beautiful.
When I scroll again, I see the full page 2.  Beautiful­.
When I scroll again, I see the bottom of page 1 (DS).  Beautiful.
When I scroll again, I see the entire bottom of page 1 (DS) + the entire top of page 2 (go to coda).  However, the bottom of page 1 (i.e. DS at the top of my screen) jumps up to accomodate displaying the next half page - makes it hard to keep reading that top of the screen.
When I scroll again, I see the entire top of page 2 (go to coda) + the entire bottom of page 2 (coda).  This time, the top of page 2 (go to coda) jumps up to the top half of the screen, again, making it hard to keep reading that portion.

I am wracking my brain to figure out a way to show the combined pages and avoid an extra page turn, but I can't find a way to prevent the jumping.  So I guess I would rather have to turn pages extra times in order to keep the page display more stable.

I have also thought about not cutting off the pages to trim the parts I don't play on the DS, however, I'll end up getting a page turn to the portion I don't need to play, and will need to page turn again to the bottom part of page 1, which will actually remove the benefit of the half-page turn.

I do want to congratulate you again on the new app, though.  It is really great and offers a lot of neat stuff!!!!

[mjlarocque]

I actually just thought of a way where it may just be possible to keep the smarts for reducing the number of page turns for small pages, yet maybe avoid the jumping up when turning:
I get the feeling that, at some point, MobileSheetsPro decides that the pages are small enough to be combined as one page. What if this was figured out one half page earlier? So that when the first small page is displayed at the top of the screen, it is already considered as combined with the following small page? I'm not sure what that would mean to the scrolling backwards, but it may be a lead into something that makes sense...

[Zubersoft]

I understand the problem you are describing, and I think I understand what you are suggesting, but I think you will still end up with a lot of situations where there are problems, and it would definitely cause issues with determining what page is active (if pages 2 and 3 are combined into one, what does it mean to activate a bookmark or link point that goes to page 3). In order for the page positions to be "stable" you still need content that is nearly half a page. So, in my testing, I chopped up many pages into sizes around a third of a page. Even if I implemented your suggestion, when two pages are combined, they would only take up about 2/3 of a page. If you then turn to the next page, I would only be able to show the top section of that page, which could only be as large as 1/3 of a page in order to still show enough of the current page to be played. I've been trying to think of any solution that solves this issue while keeping the page positions fixed, but every solution I come up with has drawbacks to it. I'm open to ideas if someone can come up with some sort of "algorithm" for positioning pages that can handle all of the different possible scenarios.

In the meantime, would you prefer I add an option to disable joining pages in half-page mode? I still think there are going to be issues even with this. For example, if pages 1 and 2 are full size, but pages 3 and 4 are only 1/4 of a page, the sequence would look like this:

(F = Full, H = Half)
1F
2H,1H
2F
3H,2H
3F (but only 1/4 of the page is used, which was already visible in the last step)
4F, 3H?

By the time you get to page 4, page 3 takes up the same amount of space as page 4, so should I shift it down or not? Should I just place page 4 on top of it, meaning there is a full page turn, so it looks more like:

3F
4F

I would think this kind of eliminates the point of the half page turns though, as it gives you no way to view 3 and 4 at the same time. I don't think there are any easy answers here...

Thanks,
Mike

[alex_hk90]

I understand the problem you are describing, and I think I understand what you are suggesting, but I think you will still end up with a lot of situations where there are problems, and it would definitely cause issues with determining what page is active (if pages 2 and 3 are combined into one, what does it mean to activate a bookmark or link point that goes to page 3). In order for the page positions to be "stable" you still need content that is nearly half a page. So, in my testing, I chopped up many pages into sizes around a third of a page. Even if I implemented your suggestion, when two pages are combined, they would only take up about 2/3 of a page. If you then turn to the next page, I would only be able to show the top section of that page, which could only be as large as 1/3 of a page in order to still show enough of the current page to be played.  I've been trying to think of any solution that solves this issue while keeping the page positions fixed, but every solution I come up with has drawbacks to it.   I'm open to ideas if someone can come up with some sort of "algorithm" for positioning pages that can handle all of the different possible scenarios.

In the meantime, would you prefer I add an option to disable joining pages in half-page mode? I still think there are going to be issues even with this. For example, if pages 1 and 2 are full size, but pages 3 and 4 are only 1/4 of a page, the sequence would look like this:

(F = Full, H = Half)
1F
2H,1H
2F
3H,2H
3F (but only 1/4 of the page is used, which was already visible in the last step)
4F, 3H?

By the time you get to page 4, page 3 takes up the same amount of space as page 4, so should I shift it down or not? Should I just place page 4 on top of it, meaning there is a full page turn, so it looks more like:

3F
4F

I would think this kind of eliminates the point of the half page turns though, as it gives you no way to view 3 and 4 at the same time. I don't think there are any easy answers here...

Thanks,
Mike

It may be a bit overkill but if there was a way of combining multiple pages (from the source file) to a single page in MobileSheets then that could help with this problem (and also be useful for stitching together sections where there are small parts that are actually relevant from a particular page, for repeats and the like). So if pages 3 and 4 are only a quarter of a page, you would (manually, with a similar interface as the cropping/annotations screen) combine them into a new page, and perhaps have some of page 2 at the start or page 5 at the end to make it a sensible amount to show on the screen at once.

[Zubersoft]

Now that I've done a lot of work with constructing new PDFs, I certainly can start to support concepts like what you mentioned. I can support converting other file types to PDF, and even to copy sections of pages on top of other pages. These kinds of features will just have to be slowly implemented over time, as it will take a fair amount of time to put together the new user interfaces and backend code.

[mjlarocque]

Now that I've done a lot of work with constructing new PDFs, I certainly can start to support concepts like what you mentioned. I can support converting other file types to PDF, and even to copy sections of pages on top of other pages (but only for PDFs).  These kinds of features will just have to be slowly implemented over time, as it will take a fair amount of time to put together the new user interfaces and backend code.

That sounds great!  I think this is what would work best.  It is indeed for repeats and codas that I run into the problem, so copying/integrating them would definitely help.

[alex_hk90]

Now that I've done a lot of work with constructing new PDFs, I certainly can start to support concepts like what you mentioned. I can support converting other file types to PDF, and even to copy sections of pages on top of other pages.  These kinds of features will just have to be slowly implemented over time, as it will take a fair amount of time to put together the new user interfaces and backend code.

That sounds perfect - thanks Mike!

[AndyL]

I would quite like to see a mode where there is nothing special about a page boundary. I would join the pages together to form one long "roll". Then a page turn would just move the roll by half the screen height. Or some other percentage of the screen height.

Maybe combining pages could produce something like this, but doing it automatically would be good.

[alex_hk90]

I would quite like to see a mode where there is nothing special about a page boundary. I would join the pages together to form one long "roll". Then a page turn would just move the roll by half the screen height. Or some other percentage of the screen height.

Maybe combining pages could produce something like this, but doing it automatically would be good.

Wouldn't this just be vertical scrolling display mode, but without the gaps between the pages and with a fixed forward/back scroll amount relating to length of 'roll' (as you put it) rather than length of page?
That sounds good to me too.

[AndyL]

Wouldn't this just be vertical scrolling display mode, but without the gaps between the pages

Maybe, but it could work equally well in landscape. Just fill each half of the screen with as much of the "roll" as fits. Then slide sideways to whatever is in the next/previous page.

That sounds good to me too. :-)

A few more votes and maybe Mike will consider it :-)