[Steinway]

Specifically, after changing the page order so that the total number of pages is increased or decreased, both annotations and cropping gets completely mismatched.

To take an example: I have a file with 5 pages. Manually cropped, and with an annotation on page 2. Page order 1-5.
I change the page order to be 5,1-5. Now the annotation on page 2 is duplicated, and appears both on the "new" page 2 (which used to be page 1) and on its original location. I change the page order back to 1-5. Now the cropping gets wrong for all the pages, and I have to manually crop the entire file again.

Galaxy Note Pro, latest version of MSP.

Anyone else seeing this?

[Zubersoft]

Unfortunately, the way many of the settings are currently saved, they are assigned to a particular page number in a song. If you modify the page order, you are changing what physical page is displayed for a logical page number. As you described above, MS Pro assigned all of the settings to page 2, but when you changed the page order, page 2 is actually page 3 after the change.

Here is the problem with the way things are currently set up. I don't assign settings based upon what page is used from the original document. If I did this, the same annotations, cropping, etc would be used on every for every instance of that page in the page order. This *may* be okay in many cases, but it could also be undesirable in a lot of other scenarios. In a simple case, like what you described above, I could probably write an algorithm to detect that the initial page range was shifted over. But what if the page range was changed to 1, 3-5, 2, 4-5, 2 (just to pick an extreme example), I don't know which page 2 I should be assigning the previous crop/annotations to. If you go in reverse, and change that back to 1-5, do I just drop the crop/annotations assigned to the second 2? These are just examples of why it becomes complicated due to the way I'm handling it.

Having said that, I have two options. The first option would be to try to fix whatever bugs are present with shifting around the page order (as best is possible with the current approach), and come up with ways to handle simple changes to the page order. The second approach would be to scrap the way I currently do things, and instead assign all annotation/crop changes to the page number in the original file instead of the position in the page order. This would simplify much of the logic, and it may even be what some people prefer, as it means if you want the annotations shared between instances of a page, this will happen automatically. I'd like to hear what people think is the best way to do things.

Thanks,
Mike

[Steinway]

Thanks for the explanation, I definitely see the problem...

For me, your second suggestion, to assign the changes to page number in the original file, makes most sense. At least for the cropping, which is often slightly different for each page, it would be desirable to have the crop values follow the same page wherever it appears. Even if I change the page order to 5,1-4,2,1-5,2, I would still like to see the original page 2 cropped the same way every time it appears.
For the 5 page example file, redoing the cropping isn't that much of a nuisance, but I often have files with 30+ pages, where the recropping takes quite some time.. I usually try to arrange the pages first (in case of repeats etc.), and then do the cropping afterwards - but sometimes, we decide to add/drop a repeat during a rehearsal, for instance, and I need to quickly be able to change the page order without messing up the cropping..

Annotations is a slightly different matter, as I can imagine many situations where you would want different annotations on different instances of the same page. I would be happy if annotations would follow the original page number, just as the cropping (if I circle a dynamic, or add fingerings etc, it would usually be desirable to show this for every instance of the same page), but people may have different opinions on this..

[itsme]

I use fakebooks as big PDFs. In some cases there are several songs on one page. So I have e.g. two songs in my library referring to the same page of the fakebook. For one song I cropped the upper part part of the page, for the other song the lower part. That's an essential feature of MSP. Please take care that this feature is not lost in case the cropping would be tied to the file page!

[itsme]

Regarding annotations: what about implementing copy/paste of all annotations of a (song) page to another one.
Then the user could copy/paste the annotations from the "wrong" page to the right one and delete them on the page where they don't fit anymore. This would be very flexible in case a page is duplicated by a page order change.

[akoster]

I use fakebooks as big PDFs. In some cases there are several songs on one page. So I have e.g. two songs in my library referring to the same page of the fakebook. For one song I cropped the upper part part of the page, for the other song the lower part. That's an essential feature of MSP. Please take care that this feature is not lost in case the cropping would be tied to the file page!

I'm sure there are many of us that would have this concern.

Regarding annotations: what about implementing copy/paste of all annotations of a (song) page to another one.
Then the user could copy/paste the annotations from the "wrong" page to the right one and delete them on the page where they don't fit anymore. This would be very flexible in case a page is duplicated by a page order change.

This sounds like it could be a good approach.

I can see cases where you would not want the same annotations on all instances of the same physical page. One example: Sometimes the dynamics are different on a repeat of a section, and I would want to highlight that on the page.

[Zubersoft]

Thanks for the feedback everyone. There are some strengths to the way I'm currently handling pages. I just need to improve how I handle page order changes, and also provide ways to make it easy to move annotations to different pages if needed. One thing that I may want to add is an option for synchronizing or copying cropping/annotations/etc for all instances of a given page in the source document. Meaning if you change the page order to include the same page in the source file multiple times, that you can choose whether or not you want to copy the existing settings from the first instance of this page to others. I just need to find a way to support features like that without it getting too confusing or error prone.

[alex_hk90]

I noticed this issue as well - for now I guess I should just make sure I get the custom page order sorted before cropping/annotating.

As for how to solve this, I wouldn't want it to (automatically) assign the cropping/annotations to the physical page in the source file, as often I have multiple versions of the same page with different cropping/annotations.

The way I envisage it could work is that when you define your custom page order you essentially define copies of the source pages, and any cropping/annotations/etc. are applied to these copies only. Any of  these copies can then be moved/copied/removed/etc. maintaining all their cropping/annotations/etc. Does this make any sense? I'm not sure I'm explaining it well.

[Zubersoft]

I think we are basically saying the same thing. It's just not entirely straight-forward to figure out which pages to copy if the same source page is already present multiple times in the page ordering and you decide to change the page order drastically. For example, if I have 1,3-4,6,1,3-4,6, and then I decide to add "1,3-4,6" again at the end, I have to decide programmatically which instance of those pages to copy annotations/cropping from. I could just default to using the first instance found in the previous page ordering, but there are plenty of times where that would be wrong, and people might argue I should use the last instance. Also, if I do something like remove some of the pages in the middle, I'm currently preserving the page the annotations are assigned to (in terms of the song's pages, not the source file) in case the user changes the page ordering multiple times in a row. This of course is why the annotations don't currently shift to match their originally assigned page. Going forward, I'm going to have to just outright delete all of the information for the pages if the page order is changed and pages are removed. People will just have to realize that changing the page order can have a large impact on what annotations/cropping values are present on a given page.

Mike

[alex_hk90]

I think we are basically saying the same thing.  It's just not entirely straight-forward to figure out which pages to copy if the same source page is already present multiple times in the page ordering and you decide to change the page order drastically.  For example, if I have 1,3-4,6,1,3-4,6, and then I decide to add "1,3-4,6" again at the end, I have to decide programmatically which instance of those pages to copy annotations/cropping from. I could just default to using the first instance found in the previous page ordering, but there are plenty of times where that would be wrong, and people might argue I should use the last instance.  Also, if I do something like remove some of the pages in the middle, I'm currently preserving the page the annotations are assigned to (in terms of the song's pages, not the source file) in case the user changes the page ordering multiple times in a row. This of course is why the annotations don't currently shift to match their originally assigned page.  Going forward, I'm going to have to just outright delete all of the information for the pages if the page order is changed and pages are removed.  People will just have to realize that changing the page order can have a large impact on what annotations/cropping values are present on a given page.

Mike

I think we're saying similar things. I agree you can't really automatically determine which instance of the source page should be copied, so instead the user should decide this.

To go through an example to illustrate how I'm thinking this could work:
- the source file has 6 pages, and when you import the file into MobileSheets it automatically creates 6 pages (in order 1-6) corresponding to the source pages;
- these pages (1,2,3,4,5,6) are now independent from the source pages (in the backend MobileSheets would think of them something like A,B,C,D,E,F), so any annotations/cropping/etc. on them will be maintained on the specific page (i.e. annotations on 2/B remain on 2/B rather than 1/A even if it is re-ordered: 2,1,3,4,5,6 = B,A,C,D,E,F) - this handles moving/re-ordering;
- for removals/deletions (i.e. 2,1,4,5,6), there would be a warning that all annotations/etc. will be lost for that page (3/C in this case);
- for adding new pages, the user would have the option of either copying an existing page or importing it from scratch from the source file: if you copy an existing page you get all the annotations/etc. from that page (e.g. from 2,1,4,5,6 you decide you want to duplicate the first 2 to get 2,1,4,5,6,2, which is actually B, so behind the scenes it creates B,A,D,E,F,G, where G is a copy of B but now independent of B and 2);
- now you have 2,1,4,5,6,2 but actually B,A,D,E,F,G so you can have different annotations/etc. on the first 2 (B) than the second 2 (G);
- if you want another copy of page 2, you can either import it from the source file (without any annotations/etc.), copy the first 2 (B) to get the annotations/etc. from that, or copy the second 2 (G) to get the annotations/etc. from that - whichever way you will get (in the backend) B,A,D,E,F,G,H (for 2,1,4,5,6,2,2 - assuming you are creating the copy at the end, there's no reason you can't create it somewhere else) and you can then move any of the 2s (B,G,H) around maintaining their annotations/etc.;
- of course MobileSheets needs to know which of the 2s you are moving, so you won't just be able to type in what you want (e.g. 2,2,1,4,5,6,2) because it will be impossible to tell which order to put the 2s, instead if there is any chance of ambiguity (as there is in this example) it should tell the user and then the user would have to select/drag/up-down the specific pages you want to move (e.g. you could long-press on the second last 2 and drag it to the front - MobileSheets would see this as moving G to the front so result in G,B,A,D,E,F,H in the back-end, and still 2,2,1,4,5,6,2 in the front-end, with no ambiguity).

Is this the solution you were thinking of as well?

[jeffn1]

I would think ay time you want to move a page, you would have a checklist asking if you want to move the following to the newly numbered page:

retain annotations yes/no
retain cropping yes/no

. . . . and anything else.

[concertmaster3]

Mike,

Would this also something implemented with a more visual page (re)ordering? Moving and copying a page would seem to keep the settings, whereas adding a page from the/a source file(?) would bring in a fresh page. This might add more memory issues though...

Sent from my SM-N910T using Tapatalk

[Zubersoft]

I don't see how it could really be very usable without switching to a more graphical interface. I'll have to dedicate an update to reworking the page ordering, as I think it will be a fair amount of work.