[Zubersoft]

We can discuss it sometime if you want to hear more about the design of the software. The major limiting factor is that a bookmark is just a reference to a song and a page. Every group type in the application expects a list of song objects, and all of the UI elements expect to be able to operate on a song object. If I switched all the groups to instead have a list of some kind of interface class that both bookmarks and songs would implement, then bookmarks could just call into the song object it is linked to to retrieve data. That would fix some of the issues, but it would be a huge overhaul that affects nearly every part of the application. Even if I get past some of the issues with how the data is accessed, I have would have to update every action in the application that can be taken on a song and figure out how it should be handled if a bookmark is being dealt with instead.  Those kinds of things would include the contextual actions on the library screen, editing the song/bookmark from the song overlay, annotations editing, the cropping editor, link points, bookmarks (adding a bookmark when a bookmark is being viewed makes no sense), the metronome, the audio player, etc, etc.  I also would have to be careful to ensure that any modifications to the bookmarks in regards to the underlying database would have to be actually made to the original song instead (using correct database id's). 

This is all doable, the question is just whether it is worth it. I would have to make significant changes across the entire application (including updates for the companion app) and that always poses major risks with introducing bugs. I'm also not sure that every user would want bookmarks to show up next to songs on the library screen (I'd probably have to make that configurable). If you do want the bookmarks to show up on the library screen, then a snippet is just as good and serves the same purpose.

Mike