[itsme]

This has been mentioned here: https://www.zubersoft.com/mobilesheets/f...12301.html
I think it makes sense to open a separate thread.

In MobileSheets sorting by SongID is not an option. It would be great, if it could be added. 
If SongID is selected as the sort field, all sorting options except Ascending / Descending should be deactivated, they don't make any sense for SongID.

I found a workaround, but it's rather inconvenient:
In "Library Settings - Song Title Formatting" insert the SongID before the title.
Use extended formatting
%SONG_ID:${VALUE} %%TITLE%
to avoid that 0 is added to songs without SongID.
Sort numerically.

If you do that, songs are sorted just "kind of" numerically by SongID. 
The exception is, that in case you have specified numbers as sort titles, these songs are sorted in-between.

[itsme]

I'm experimenting just recently with using SongIDs to share setlists. Every member of my band runs his own MobileSheets database, has his own song files and uses his individual naming conventions for the songs. Tired of having everyone editing his own setlists again and again I thought about a better solution. It seems a good idea to specify a SongID for every song in our repertoire. Every band member has to edit the SongIDs once in his individual database and from then on one of us can create a setlist and write it into a .mss file via "Share - Export song list". The others import that .mss file to create a setlist with the same name containing the same songs. As far as I investigated that, it seems to work fine.

Anybody out there who has experience with a similar workflow?

@Mike: what are your concerns against such a usage in detail? you mentioned several things in the other thread? We dont synchronize databases and we don't connect tablets by now.

We could use it "as is", but there's room for improvements:

Displaying the SongIDs and sorting by SongID is required to make sure that all band members have specified the same SongID for the same song.

It would be useful if MobileSheets made sure that SongIDs are unique per database. Currently it is possible to assign the same SongID to several songs which leads to undefined behaviour when a .mss file is imported.

Filtering by SongID could be improved:
Currently the SongID field can be selected in the search bar, but to find a specific SongID it has to be entered completely. Searching for SongID = 0 helps to identify songs without SongID, but there's no possibility to search for songs with any SongID or search for a range of SongIDs.

Readability of .mss files (as well as many other config files of MobileSheets) could be improved:
Currently .mss files don't contain any line breaks so they are impossible to read. My favorite text editor Notepad++ has an XML plugin with a "Pretty Print" feature that integrates line breaks and indentations into XML files. If I apply that to a .mss file it becomes nicely readable and still works fine. Such a kind of formatting could already be part of Mobile Sheets
   

If a .mss file with a setlist name that already exists in the database is imported (and the respective warning of MobileSheets is ignored) two setlists with the same name exist. It is not visible which one is which. It would be better if MobileSheets added a postfix like _1, _2 ... to make the setlist name unique or provide an option to modify the name during import.

[Zubersoft]

If you populate the song ID field and share a .mss file, if that .mss file is imported on another device, a setlist will be constructed to match, and every song will default by trying to match on song ID first. If users populated that field without understanding the consequences, their setlist would appear to have random songs in it that don't match the titles from the other tablet. That's what I'm worried about with users misusing that field just as a piece of metadata. This applies to .msf files too - the wrong song could be updated if a .msf file is imported and song ID was populated on both devices without realizing the implications. This also applies to the library synchronization feature (I recently had to help unravel sync issues for a user because of this). So this costs me time with customer support.

I do have plans to add code to force song IDs to be unique, as I do agree that it is problematic otherwise. I also want to split the song ID field up, and have two different fields: song ID, and synchronization ID. The former would be just for display purposes, and I could make it an open text field so that users can enter anything (like the custom field). The synchronization ID would be for matching purposes, and would be hidden by default to prevent accidental use. The only thing I have to decide on is how to handle entries that users have already added. I could just duplicate the same value to each field so I don't break libraries that are utilizing song ID correctly, but this wouldn't fix the libraries of the users who didn't use it correctly.

As far as formatting, it turns out I can set a flag to have indented output, so I just switched that on - thanks. I'll have to consider new song ID filtering options when I rework the filters.

I'll make the change for the duplicate setlist detection if the option to create was selected instead of update, and we will see if anyone complains about the change in behavior.

Mike

[itsme]

Thank you for your detailed reply.
It still sounds like I'm close to the intended use case of SongID and .mss file, or how else was your original plan to populate the SongID?
Anyway, I feel like it would be better to wait for another step of your implementation and investigate some more before I motivate my colleagues to invest time in populating SongIDs in their databases.

Searching the forum for SongID found (there's more, but these seem to be the interesting threads):

Sciurius: Song ID
(visible SongID vs. internal datatbase ID)
https://www.zubersoft.com/mobilesheets/f...-5240.html

Oz Cello: MSP for string quartet/small ensembles
(connected tablets used for playing different parts of the same song)
https://www.zubersoft.com/mobilesheets/f...-6413.html

kabakakao: SongID alphanumerical
https://www.zubersoft.com/mobilesheets/f...-11943.htm

mdavej: Database Fields Best Practice
(Collection, SongID and Custom Group)
https://www.zubersoft.com/mobilesheets/f...11454.html

[Zubersoft]

Yes, it does sound like you are using it as intended, at least as far as sharing the setlists. I would still prefer to have two separate fields, and have the synchronization ID be something that's more "behind the scenes" and not something you would filter or sort on, although I imagine for some users they would put the same value in both fields.

Mike

[BRX]

I think this a very interesting discussion. I'm intrigued by having an additional sync ID. Have I understood correctly that song ID would be for the (complete) syncing between (own) devices and the sync ID more for sharing/syncing with other people but not the whole database but setlists etc with MSS?

If not I like to propose these additional sharing options

- Sharing a setlist as MSS (or other format) without the song files. Only files on the other device with the same sync ID are used for the setlst on the receiving end.
- Sharing a setlist as MSS with the song files. Files on the other device with the same sync ID are used for the setlist and not changed or replaced. The songs in the MSS with the same sync ID 
  are ignored, non matching files are added to the database and the setlist on the receiving end.
- Lastly also an option to overwrite the files with same sync ID on the receiving end in case one wants to share changes in the song, replacing them inclsuive annotations, but keeping the folder 
- structure/path.

The last two options would solve problems for me with syncing changes from my iPad to Windows and Android (and vice versa) without disturbing or destroying the folder structures I created and want to keep.

[itsme]

.MSS is an XML file without song files, see attachment above
it is created by selecting a setlist and calling "Share - Export song list" (Teilen - Songliste exportieren)

.MSF contains the list of songs including the song files 
it is created by selecting a setlist and calling "Share - Export songs and files" (Teilen - Songs und Dateien exportieren)
(what BRX proposes as 'setlist as MSS with the song files')

When importing these files, they are applied to the database they are imported into, the 'destination database'. Songs without SongID are identified by the combination of title and (first) file. Songs with SongID are identified by SongID. In both cases the destination database is searched and the songs in the destination database are used. This is what Mike is warning of: if you import an MSF file into a different database and a different song is found, the file from the MSF file overwrites the one in the database. This has the potential to completely confuse the destination database if you don't know what you are doing.

In case you import an MSS file and no matching song is found, MobileSheets creates an empty song, gives it the titel from the MSS file, adds a single blank page and adds that empty song to the setlist.
Open question: how to find those empty songs in a huge database? 
If I create an empty song manually, I have to add at least a blank page. 'Blank Page' is written into the file path, so I can find it by selecting 'File Paths' as search field and search for 'Blank'. For empty songs that were created by importing an MSS file this doesn't work.

[BRX]

Yes, I mixed up MSS and MSF. I meant MSS for the first item and MSF for the other ones, of course.

[Zubersoft]

I was suggesting having song ID be purely informational (like the custom field) and be disconnected from its purpose with linking songs between libraries. The synchronization ID field would take over what the song ID is currently being used for (by some users).

As far as identifying blank songs, there isn't an easy way to do that at the moment... I'll have to adjust the .mss behavior so that it provides the same type of file name as it does when adding a blank page in the song editor.

Mike

[Zubersoft]

So it turns out that the current behavior with blank pages is not what I intended.... it populates the path with "1 Blank Page" (or however many blank pages were added) in the song editor. I had always intended for the path to be blank for blank files, as there is no file. So your current approach to being able to filter on them is actually an unintended consequence of this mistake. However, things seem to be working fine, and I'm not aware of any issues with blank files due to this (because I have explicit handling of blank files in various parts of the app like when exporting), so I'll keep it the way it is. I'll also adjust the mss code to populate the file name with "1 Blank Page" to match what the song editor is doing, even if this isn't what I originally wanted.

Mike

[itsme]

So how about my idea of using SongID for sharing MSS setlists? Shall we use SongID or synchronization ID? Will MobileSheets take care of making it unique (whatever will be used)?
It was not my intention to reinvent the wheel. I thought that the existing implementation could be used and needed only a little bit of fine-tuning.

[BRX]

Mike, help me understand this. Maybe I've been worrying too much and MS is already doing what I want.

My scenario: I've songs in a collection (big band music) on my iPad and on a Windows PC with mostly identical songs (same songID I guess because I transfered the database from Windows to iOS with the backup funktion initially).

If I want to "sync" songs with some annotations I did on the iPad to Windows (and don't want to sync the complete database) can I just transfer them with MSF (yes, I know I can but ...) and does it replace the file on the Windows PC and keep the file structure (folders) intact (files in the same place)?

Does it check the songID for importing by MSF for this or only the title names (since I have many songs with the same title in the database)?