08-22-2023, 04:05 AM
So this is a little problematic unfortunately. The issue is that MobileSheets does not parse the key information out of the database for every song until the song is actually loaded. There is a large amount of data that is handled this way to keep the memory usage lower and speed up the initialization time. In order to support this, I would have to modify the code so that it first checks to see if the user has specified a format string containing the new transpose field, and if they do use that, I'd have to take one of several paths:
1) Read out this format string from the database every time any tab is updated on the library screen. I don't want to cache this information as then I have to modify tons of code everywhere to update the cached information any time a song is transposed, deleted, created, copied, etc. Reading from the database in this manner will be slow, especially with a large library.
2) I'd have to initialize every song in the entire library. This would significantly increase memory usage and slow down the initialization of the app, but then things would work smoothly after the initialization. As long as the app has plenty of available memory, this isn't an issue, but it could certainly become a problem with users with very large libraries (especially if they have a lot of annotations).
3) I'd have to modify the database to store the key as part of the basic file information which is read out at app startup. This would require updating code throughout the entire application to update that field in the database if the songs are transposed, and it would create redundancy between the basic file table and the one that stores text file specific information. It would prevent the need to have to read out additional information though.
The simplest option is probably #2, and I'd prefer to keep this simple as most users won't utilize it, so I can move forward with this, but that's going to be the downside of it.
Mike
1) Read out this format string from the database every time any tab is updated on the library screen. I don't want to cache this information as then I have to modify tons of code everywhere to update the cached information any time a song is transposed, deleted, created, copied, etc. Reading from the database in this manner will be slow, especially with a large library.
2) I'd have to initialize every song in the entire library. This would significantly increase memory usage and slow down the initialization of the app, but then things would work smoothly after the initialization. As long as the app has plenty of available memory, this isn't an issue, but it could certainly become a problem with users with very large libraries (especially if they have a lot of annotations).
3) I'd have to modify the database to store the key as part of the basic file information which is read out at app startup. This would require updating code throughout the entire application to update that field in the database if the songs are transposed, and it would create redundancy between the basic file table and the one that stores text file specific information. It would prevent the need to have to read out additional information though.
The simplest option is probably #2, and I'd prefer to keep this simple as most users won't utilize it, so I can move forward with this, but that's going to be the downside of it.
Mike