03-26-2023, 05:55 PM
Mike, I was just trying to think of the different use cases that you might want to target the versioning feature at. Did you have a list in mind? For example:
1. having a song in multiple keys
2. having a song for different instruments
3. having a song with different sheet music for use in different bands
4. using leader/follower to load different parts (or the score/piano reduction etc) from the same piece on connected devices
5. having the same score but with different annotations (e.g. for different students learning the same piece, or performances of the same piece with different groups and hence different fingerings/bowings/dynamics/repeats etc)
I think you're right that you'll need a separate library entry for each version. The alternative of having each version somehow be a sub-unit of an entry seems like it would be harder to implement without rewriting the UI from the ground up. With separate library entries for each version you'd definitely have the potential for clutter though. I wonder whether it would be possible to have the option to collapse all the versions of a particular work on a given library display into a single library entry. Perhaps a button to expand/collapse all, and/or a way of collapsing/expanding individual entries? You'd want the library entry for each version of a piece to say which version it is - that might involve making a UI to help create relevant subtitles/captions rather than users having to create them by hand.
You'll need a way of linking versions of the same work. I'd probably go with making the app assume that all entries with the same sorted title are versions of each other but there would certainly be other ways of doing it such as asking if a song should be linked to an already-imported song when it's first created, with the option of manually linking two entries after they've both been created.
I was imagining versioning as an advanced filter system. 1, 2 and 3 above could all be handled with the filter system using the same attributes you currently have. You might need to upgrade the filter system to better handle situations where files have been filtered out, and to make filtering a bit easier (e.g. the ability to choose which attributes can be filtered directly from the filter bar without having to go to a sub-menu). I imagine you'd want the filtering to be seamless - if you filter out everything apart from parts in a particular key then you want the library to look and act like parts in other keys don't exist. You'd probably have to make sure that filtering on more than one attribute would work as intended too. I think that might've been a problem at some point but not sure if it still is.
4 above could also be implemented with a filter but you'd need to upgrade the device link system to make sure the right version is displayed (e.g. in my case, playing cello in a string quartet, if I have all the quartet parts in my library then I filter for cello parts, when the first violin loads a piece, my tablet will make sure it loads the cello part of that piece).
I imagine 5 above can already be achieved to an extent with annotation layers - a piece of student repertoire has a layer for student 1, another for student 2 etc. It could be useful to have each student's copy of the piece be a separate library entry (and be a version of the same piece) so that you could then filter for that student and then any piece you load would have the markings for that student. Same for markings for different performances of the same work. If you have a separate version with separate annotations for each time you perform a particular piece then you could look back and see what bowings etc you did last time, but you could also filter for the current performance and have the right markings for each piece in the current programme load automatically.
Implementing versions that way would mean creating a separate entry for each version but I can't think of a good alternative to that, and the UI could make it a bit easier - for example if you have a pdf containing the score and parts for a work and you create an entry containing the score then you could have an option (similar to snippet) to create a version from that entry which could be one of the parts. Creating a version for all the parts would be fairly quick.
In terms of creating setlists/collections etc you'd want to make sure that it's clear when you create one whether you're adding some or all of the versions available. In my case I'd probably be adding all the versions (the four quartet parts) but I imagine it would be come to need to create a setlist with just the versions for the band playing that list, or just the versions for the instrument you're on for that show etc.
I don't know whether any of that would cause problems for your file system. Having multiple folders with the same name seems to cause problems occasionally with back-ups/syncs.
Anyway, just some thoughts. Guy
1. having a song in multiple keys
2. having a song for different instruments
3. having a song with different sheet music for use in different bands
4. using leader/follower to load different parts (or the score/piano reduction etc) from the same piece on connected devices
5. having the same score but with different annotations (e.g. for different students learning the same piece, or performances of the same piece with different groups and hence different fingerings/bowings/dynamics/repeats etc)
I think you're right that you'll need a separate library entry for each version. The alternative of having each version somehow be a sub-unit of an entry seems like it would be harder to implement without rewriting the UI from the ground up. With separate library entries for each version you'd definitely have the potential for clutter though. I wonder whether it would be possible to have the option to collapse all the versions of a particular work on a given library display into a single library entry. Perhaps a button to expand/collapse all, and/or a way of collapsing/expanding individual entries? You'd want the library entry for each version of a piece to say which version it is - that might involve making a UI to help create relevant subtitles/captions rather than users having to create them by hand.
You'll need a way of linking versions of the same work. I'd probably go with making the app assume that all entries with the same sorted title are versions of each other but there would certainly be other ways of doing it such as asking if a song should be linked to an already-imported song when it's first created, with the option of manually linking two entries after they've both been created.
I was imagining versioning as an advanced filter system. 1, 2 and 3 above could all be handled with the filter system using the same attributes you currently have. You might need to upgrade the filter system to better handle situations where files have been filtered out, and to make filtering a bit easier (e.g. the ability to choose which attributes can be filtered directly from the filter bar without having to go to a sub-menu). I imagine you'd want the filtering to be seamless - if you filter out everything apart from parts in a particular key then you want the library to look and act like parts in other keys don't exist. You'd probably have to make sure that filtering on more than one attribute would work as intended too. I think that might've been a problem at some point but not sure if it still is.
4 above could also be implemented with a filter but you'd need to upgrade the device link system to make sure the right version is displayed (e.g. in my case, playing cello in a string quartet, if I have all the quartet parts in my library then I filter for cello parts, when the first violin loads a piece, my tablet will make sure it loads the cello part of that piece).
I imagine 5 above can already be achieved to an extent with annotation layers - a piece of student repertoire has a layer for student 1, another for student 2 etc. It could be useful to have each student's copy of the piece be a separate library entry (and be a version of the same piece) so that you could then filter for that student and then any piece you load would have the markings for that student. Same for markings for different performances of the same work. If you have a separate version with separate annotations for each time you perform a particular piece then you could look back and see what bowings etc you did last time, but you could also filter for the current performance and have the right markings for each piece in the current programme load automatically.
Implementing versions that way would mean creating a separate entry for each version but I can't think of a good alternative to that, and the UI could make it a bit easier - for example if you have a pdf containing the score and parts for a work and you create an entry containing the score then you could have an option (similar to snippet) to create a version from that entry which could be one of the parts. Creating a version for all the parts would be fairly quick.
In terms of creating setlists/collections etc you'd want to make sure that it's clear when you create one whether you're adding some or all of the versions available. In my case I'd probably be adding all the versions (the four quartet parts) but I imagine it would be come to need to create a setlist with just the versions for the band playing that list, or just the versions for the instrument you're on for that show etc.
I don't know whether any of that would cause problems for your file system. Having multiple folders with the same name seems to cause problems occasionally with back-ups/syncs.
Anyway, just some thoughts. Guy