[carlo]

Hello,
I'm trying to understand how snippets work in MobileSheets. From what I gather, snippets do not actually duplicate a portion of a score, but rather create a reference to a section of the original file.
However, I've noticed that when I add an annotation to a snippet, that annotation does not appear in the original file. I was expecting the annotation to be visible in both, since the snippet is not a true copy but rather a reference.
Could someone clarify how this works? Are annotations in snippets independent from the original file, or is there a way to ensure they appear in both?
Apologies if this topic has already been discussed elsewhere—I tried searching but couldn’t find a clear answer.
Thanks in advance for your help!

[Zubersoft]

A snippet is a new song that references the same file as the original but with a different page order. Annotations are not stored in the PDF - they are stored in the MobileSheets database and are separate for each song. However, if you do want them to be embedded in the PDF, you can use the "Embed Annotations" option in the annotations editor to make that happen. Then the annotations would show up in every song that uses the same file.

Mike

[carlo]

Thanks, Mike! I appreciate the explanation.
I tried the "Embed Annotations" option, and it does work, but I noticed two drawbacks that limit the advantages of using snippets (considering that my workflow mainly consists of applying fingering to organ music scores):

1. The editability of annotations—especially deletion—seems to be only partial. Deleting annotations appears to happen in "blocks" rather than allowing precise removal.
   
2. Since the PDF seems to be rewritten each time the annotation editor is closed, this process can take a long time for large files. In my case, a ~100MB file takes 40 seconds to process on an Windows 11 PC (i7-4770/32GB/3.40GHz)).
   

Granted, in my case, an alternative could be to embed the annotations only once they are finalized.
I assume this behavior is due to the inherent limitations of embedding annotations directly into the PDF. Are there any alternative solutions in development or under consideration, similar to how ForScore handles this without the same performance issues?
Thanks again for your help!

[Zubersoft]

I'm really not sure why you are seeing those performance issues. How many pages is that 100 MB PDF? The PDF library should only be embedding and modifying pages that were actually changed, not all of the pages. I might need to have you export your song to .msf (right-click the song, click Share->Export as .msf and share the .msf with mike@zubersoft.com) so I can see if I can reproduce the issue you are describing to see if there is a potential solution. 

As far as the deletion issue, select the annotations individually (either with the selection tool or the layers window) and then you can delete them directly without using the eraser tool.

Mike

[mancunius]

Has this gone any further? My issue is that if, for example, I have a suite of 10 movements and want to play 4 of them as part of a set list, interspersed with other pieces, creating a snippet seems to be the only way to facilitate this easily. But then the markings (fingering for example) I add to the snippets are not part of the original book and that's a real problem for me: there will be occasions when I want to play the entire suite and the markings are now missing from some movements.

Are there any other solutions? I don't think embedding would work for me as I'm always in a state of flux. Allowing bookmarks, or the pages between them, to be added to a setlist would be good.

In summary I just want it to work as if I'd made pencil markings in a physical book, but without the hassle of turning backwards and forwards when I'm playing extracts.

Thank you,

Mancunius

[Zubersoft]

If you don't want to embed annotations, then there is no easy solution. It's going to requires substantial design changes to tackle to this problem. The idea of adding "bookmarks" to a setlist sounds fine but the only way I would envision that working is having to disable certain parts of the application when working with a bookmark, as otherwise some actions wouldn't make sense when working with a bookmark vs the full song. The biggest problem will most likely be with dealing with database updates caused by an update to the parts of the song referenced in the bookmark, which means adding another layer of indirection between understanding what the current page really maps to in certain contexts (page in terms of the setlist -> bookmark page -> song page -> PDF page). There are many scenarios that are going to get messy with this, such as - if you have a bookmark to pages 6 through 8 tied to a song, then you edit the song and change the file and those page numbers are either no longer valid or offset, how should the bookmark be updated? Sometimes it will be obvious, sometimes it will not be. Do I just leave bookmarks as invalid past that point? Do I then have to add large amounts of warnings to users every time they make an action that could potentially impact bookmarks tied to a song? 

I'm sure it will be possible to figure out all these answers with enough time and work, but it's certainly not a small change.

I have to say, I don't like the idea of using the term "bookmark" in reference to something that actually represents a range of pages. A physical bookmark just marks a single page. That's how a table of contents reference works, how PDF bookmarks work, etc. That's why I went with the term snippet. I'm not sure what the best term is for this, but if I want to support having a reference to a page range from a song that can be referenced in a setlist, I'd rather either change the snippet implementation so it supports either mode of operation, or come up a with a new term that doesn't have an overloaded meaning. I know apps like forScore have handled bookmarks this way - I'm saying I disagree with using that terminology as it's confusing in my opinion.

Mike

[mancunius]

Hi Mike and many thanks for responding. I agree with you about bookmarks - they are points rather than collections of pages. And thank you for explaining the issues with the design on this issue. I guess it's not as easy as telling it that a snippet just refers to pages xx-yy of a bigger file as snippets allow editing of page orders etc which go beyond this.

I think probably my best way forwards is always to play from snippets in these circumstances and leave the big collections unmarked, then there's no confusion. I just need to set up the habit!

Love the app by the way.

Thanks, M