MobileSheets Forums

Full Version: Unreachable annotations
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
* A two page ChordPro file.
* Put some annotations on the 2nd page.
* Replace the ChordPro file (eg., swap) by a new file that has only one page.

The annotations are now out of reach. You can't see them, you can't remove them.

Replacing the file with a longer song (at least 2 pages) will make the annotations on the 2nd page visible again.

I'm not sure what would be the proper way to deal with this situation. A dialog similar to "Updating this song file causes annotations to be discarded"? Or just discard silently?
The reason I don't delete the annotations is that a chord pro file has no defined length. If you just increase the text size enough for the new chord pro file, it would extend to two pages, making the annotations visible again. Are the annotations even useful at that point? Probably not. So maybe it is better to just ask the user if they want to delete them in that case, but I erred on the side of caution. Other than having extra data in the database that isn't used, I'm not sure there is a large penalty to leaving the annotations in place even if they aren't visible.

A hint for the user that the song has invisible annotations might be helpful.

And a similar issue comes up if I bring a chordpro file with annotations to a device with a different screen size:
the song will be reformatted and the annotations won't stay at their position.
The fact that annotations can't be embedded in the chord pro file, and that the rendering of the chord pro file will be different depending upon the device resolution and aspect ratio means that ensuring the annotations are represented the same on every device is incredibly difficult. I have some proposed solutions for how to handle this issue, but they are going to require some difficult changes. I will basically have to start storing a lot more information about the screen dimensions of the tablet that generated each annotation (increasing the amount of data required to store and load the annotations) so that I can figure out on other devices how to properly scale the annotations so that they look the same. With PDFs, this isn't a problem because I'm currently storing the amount the page was scaled when the annotation was created in the database. So if the page is scaled a different amount on a different device, I can just scale by the delta between what the annotation was created with and the current page scaling factor. With a chord pro file, there isn't a scaling factor at all, so it's always saved as "1". This means that the annotations aren't scaled at all on a different device. So if I at least save the tablet dimensions with the annotation, I can know what the delta is between the two tablet dimensions, and scale by that. I believe it should work, but it won't fix annotations that are part of a library that were generated on a different device. I believe there were some other considerations as well, but I would need to review my notes on it.

I agree that keeping annotations in place has too many difficulties.
Keeping annotations in the database instead of discarding them seems OK for me, but the user should know about it and should be able to delete or move these annotations.
How about something like a button or a control that becomes available when invisible annotations exist? Pressing that button could automatically add as many empty pages as necessary to show the annotations.
One option would be - if I detect that the song has annotations on pages, I force the chord pro file to be that many pages regardless of how many pages would be rendered normally. At least that way the annotations could be reached. The annoying part is that if the annotations are then changed, I will have to check each time to see if pages need to be removed and handle that accordingly. If a chord pro file is one page, but there are annotations on page 2 and 3, and the user removes all annotations on page 2, I then have to change all annotations on page 3 to page 2 and adjust the page length, etc. It certainly is tedious and introduces the possibility of bugs, but if you guys prefer that, I can certainly do it. I could also just leave blank pages in place up until the last page containing annotations, which is probably a simpler solution that is less error prone.

If it's just better to prompt to accept that the annotations will be deleted from non-visible pages after the file swap occurs, I can do that.

All I can do is give my personal opinion, which is related on my work flow.

When working with ChordPro songs, annotations are almost always a signal the song file needs updating. For example, during a rehearsal I may strike a chord, add a different chord, add a note like "Intro: 4 measures" and so on. Later when I'm home I process the annotations and turn them into changes to the ChordPro file. The chord is changed, the note is added as a {comment} and so on. Then I upload the modified file, check the results, and remove all annotations. So in my situation is it quite exceptional for a ChordPro song to have anything but temporary annotations. I even have a small tool (SQLite query) that reports which songs still have annotations. That's how I found out about the unreachable annotations.

When a ChordPro song file changes, or its visual rendition changes, most, if not all, existing annotations lose their relations with the surrounding text and become pointless. This is inherent to the dynamic formatting that is unique to ChordPro songs.

So AFAIC annotations may get lost upon reformatting, if possible with a warning dialog.

A nice, but not easy to implement solution would be to display the old and new pages side by side, and offer the possibility to manually move annotations to a new location in the new song. Personally, again, I consider other things more important to implement.