[BRX]

Hi Mike,

as you mentioned versioning is your next big project in MSP.

Since you certainly have to consider certain UI and db changes I wanted to share some ideas and suggestions you
might use in these changes which I consider sort of "versioning" as well.

It's my understanding that your planned changes allow to have certain versions of a song which use the same
source file but can have different annotations, page order etc. without the need to create a snippet or new
song. Have I got that right? (That in itself would already be an awesome new feature).

But I'd like to expand on that. I'd like it if you could also add other song versions (of the same song with the
same title) to a "main song".

I know it's not politically correct anymore but for the sake of explanation let's say you indicate one song
as a master song (with a checkbox or something like that) and you can assign other songs (including the new versions
feature) as "slave songs".

Since the publication of the Windows version (and probably it could be the same for Mac users with the iOS version)
for me MSP isn't only a mobile sheet viewer for tablets and sheet reading any more but a powerful organization
tool for my sheets collection. Much like calibre is for ebooks.

It's nice to have the whole collection on the PC organzied by MSP (and have smaller parts, with separate libraries for the mobile
tablets if necessary).

I'd like to be able just to search for or browse such master versions (just to reduce the sheer amount of songs and not to
have 50 entries for All The Things You Are or Yesterday visible), which can be expanded to show the other "slave versions" if necessary.

Even more important I'd like the entries for the master version for composer etc. to be valid for all the other versions
as well so they are automatically applied for the slave versions and you only have to put them into the master version, but
can also search and filter by the entry for the slave versions even if the fields aren't filled for them.

Am I making sense? So if I have a master entry of All the things you are with all fields like composer etc. filled and 20
other slave song entries without them filled out a search or filter would still display all the versions.
(If there is an entry in a slave version that should overrule the master entry though, I think).

Probably the size of the db could be much smaller as well if you just have to put the entries into the master song.

Is this something you consider useful and doable for the versioning (or even at a later time)?

[Zubersoft]

Yes, your understanding of my planned changes is correct. I'm not really sure how what you have described differs from my plan though. It's already going to be set up so that there is one song entry, and it will be possible to switch versions depending on what you want. I'm also going to have to handle applying changes in one version to other versions, so the idea of having a "master" song is really just a detail in how you plan to use the versioning feature. I imagine you will be able to just say the first version is the "master" and treat it as such when applying changes to other versions. I'll have to make sure it's easy when making changes to fields to indicate which versions should be updated with the changes, as managing multiple versions will become really burdensome otherwise.

I do have one comment about this though based on your feedback - I still have to think through some of the implementation details, but when a song is added to a group type like collection, I haven't decided yet whether I'm going to allow multiple versions of the same song to show up in the list, or just one instance of the song but you can change which version to use. I'm thinking in order for it to make sense, each version of a song would have to show up in the list (as some versions of the song may be in the collection but not others). The other way of handling it would be to not allow different metadata for each version of a song, meaning each version still has to have the same collections, genres, albums, etc, assigned, but that would be very limiting in terms of how the versioning could be used, so I don't think I like that idea. 

Assuming I choose to allow multiple versions of a song in the list (which is the direction I'm leaning), if you want to be able to search for certain versions of a song in a particular group, you will have to add all of the versions to that group. As I mentioned previously, I plan to make this easy so that you can apply metadata changes in one version to other versions, so it shouldn't require much extra effort to do this. I could also have a checkbox for each field or all fields that indicates whether the metadata is synchronized for all versions of the song - that may be the simplest way to handle it. So users can manually manage the metadata if desired with tools to make it easy to apply individual metadata fields to other versions, but the default will be to always use the same metadata for all versions.

I can imagine this will create scenarios where things get a little messy - let's say you have 20 versions of a song, and the option to keep the metadata is synchronized is active, and you had the song to a collection. Well now it's going to show that 20 versions of that song are in the collection, and if you click the option to "Load All" for the collection, it's going to load all 20 versions of the song. I doubt that is what most users would want though, so then I'm kind of stuck between whether I should show all versions, whether all versions should be loaded, and finding a way to support both scenarios where users can choose whether all versions should be present without having to manually manage the metadata for every version. The versioning is definitely going to be a major pain to implement.


Mike

[Oz Cello]

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

[otnt]

What is the difference between "versioning" and making a copy of the same song/piece and renaming it and adding key, instrument, band to a title? It is already available.

[Zubersoft]

There are several scenarios where having multiple versions of a song is going to be important to some users:

1) In a band/orchestra/choir where a single central library contains every song entry, but each musician may need to view a different version of a particular score. When using the "Connect Tablets" feature to have one person control the other tablets, there is no good solution to handle this, because if you had a different song entry for each version, then the conductor/leader can't just load one song and everyone else immediately sees the correct version they need. The song versioning will solve this because you can have multiple versions of one song, and I plan to add a "role" type setting which lets you assign a version to a particular role. Each musician then only needs to change one toggle (their role) and they will always see the correct version of every song in the library without having to fiddle with anything.

2) Many users want one version of a song for practicing and one for performance. If this is done for every song in the library, the song list gets incredibly cluttered. Having one song entry with multiple versions means it would be simple to change between practice and performance (especially if coupled with a role for each given my plans described above).

3) Having multiple entries of a song in multiple keys. Similar to number #2, some musicians play multiple instruments, and while they can effectively accomplish separating songs per instrument using collections or different libraries, having multiple versions and a way to easily switch versions depending on which instrument is played may be a superior solution in some situations.

To clarify, with the song versioning, the plan is that each song version can have different metadata, files, annotations, link points, bookmarks, etc (although as described above, I'm still thinking through the metadata part of it). There will just be one entry on the library screen, and a dropdown that lets you switch versions. When adding a song to a setlist, it will be possible to choose which version of the song to use in the setlist.

The song versioning will take many months to implement and test, as I have to make changes on all three platforms and the companion app, and also test every feature in the application with all the different combinations of settings.

Mike

[Oz Cello]

Mike, that all sounds great. I look forward to seeing how you implement it. Please let me know if I can help with testing. I'd mainly be using the first scenario. I currently achieve it by using a separate library for each version but it will simplify things greatly to have all the versions in one library. One of the benefits of having separate libraries is that it's almost impossible to accidentally switch to the wrong part. Each device has all the libraries on it but is mainly used with just one of them. What that means is that if we have a new player sitting in on say, second violin, we can just give them the second violin tablet knowing that it will already be set to the relevant library and that that player will only see second violin parts and won't easily be able to accidentally switch to the wrong parts. That's very helpful if they're not familiar with the devices or the app. It would be great to be able to keep that capability when the parts are all moved to one library, i.e. to be able to toggle a particular device to a particular role, and have that role persist through power cycles, and make it difficult to accidentally switch roles. We generally leave the filters hidden on the devices that aren't the leader so that noobs don't accidentally filter any parts out. It would be good to be able to do the same thing with the toggle for roles. Guy