[RoSong]

Hi - I use a combination of pdfs, in either lead sheet or piano with vocal line styles, and chordpro files. This is a request for the chordpro songs that can be transposed. 

On many chordpro songs, I switch the key with the transpose button, and I may not do a song in the same key every time. Sometimes for the vocal range of the song, and sometimes to fit with the other songs in a setlist. It's confusing for my song title to show C, then on opening it, I find I have previously set it to D, for example. And in a setlist where I'm playing several songs in the same key and I've adjusted a chordpro file to accomodate that, but the titles in the setlist still show the original.
 
 I would find it very helpful in both the library window and in the setlists, if there could be an extra field showing the current transposed key in addition to the original key of the text file. Then I could tell at a glance, which key a song was transposed at any given moment.

Is it possible to utilize the transpose box as a "field" that could be used in the song title formatting in the library settings? 

So for example, I have my title format set like this: 

%TITLE%  %KEYS:-  ${VALUE}%  %SIGNATURES:-  ${VALUE}%  %TEMPOS:-  ${VALUE}% 

So if there could be a button for "transposed" field, just in the formatting window, it could be included after the key, and could beformatted to show (D) or "D" or tr-D. Obviously, this would apply to only chordpro files and all the other files would just have a blank spot where that would show up.

For example: 
A pdf file might show: How Great Thou Art - C -  - 4/4
And the Chordpro file might show: How Great Thou Art - C - (tr D) - 4/4

I know the other fields are actual fields that can be shown on tabs,sorted, etc. I don't think it would be necessary for this field, but if there's a way for it to show up as a button in the song formatting window would be great. 

Another feature request that might be useful is to have a setting under the three dots, after selecting one's chosen songs, to reset those songs to original key. A popup could say "no chordpro songs were selected" if only pdfs were chosen. Or if I picked, say 4 songs, and only one had been transposed, the popup could say "1 chordpro song was reset to original key"

[itsme]

Adding the "transpose" value to the selectable fields for song title formatting is a very good idea, I support that.

With that feature I could fix a scenario that always bothered me! How could it happen that I didn't propose this earlier!
I like the possibility to transpose ChordPro files and use it frequently:
In case I play a song in two different bands in different keys I often use the same Chordpro file with different transpose settings. I use "copy song" and change the key, both the transpose setting and the "key" entry for the database in the song editor. So it's common that several copies of the song exist in my database, "key" is always filled out and displayed in all lists via song title formatting.
In case a different key is requested in a session or a rehearsal I can transpose a song easily as required. Great. So far.
But it's so easy to forget to reset the transpose value! Especially when just pushing "reset" in the transpose dialog is not the way to go, but looking up the "right" key for that song version and setting transpose correctly is necessary. And the session goes on and my concentration is everywhere else than maintaining my database ...
With the "transposed" value in song title formatting that could be handled easily.
Whenever the transposed key is different to "key" (as in RoSong's example "How Great Thou Art - C - (tr D)") the transpose value of that songs needs my attention. And I could handle it quietly at my desk at home going through the recent list of the last session or while preparing a setlist for the next gig.

I did not miss "transpose" as a field in the song editor so far and I also did not miss a possibility to reset the transpose value for several songs in one step, but that might be different for other users like e.g. RoSong.

[itsme]

One more use case for user defined song title formats that I proposed earlier
https://zubersoft.com/mobilesheets/forum...-9684.html

[RoSong]

Thank you for your support for this idea, itsme - it was one of your posts I followed to learn how to use the % symbols and value tags to get the song title formatting how I wanted it.

I just followed your link and I like that idea, too. I have copied and pasted my long strings to a notepad app that can adjusted outside of MS & then pasted it in. It would be great to save different strings in MS.

[Zubersoft]

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

[RoSong]

Thanks Mike for explaining. It makes sense. I suspected it probably wouldn't be a straight-forward matter. Most users would probably not be happy with a longer start-up time than they are used to and I wouldn't want to jeodardize memory issues. I think there are a lot of users that use annotations extensively. I ues them some, and I'm also dealing with an ipad with not much extra space on it. So the trade-off may not be worth it. 

It would be nice, though, if a simple way were found to exist.

[Zubersoft]

I will see what I can do. There may be a middle ground I can take that will only incur a slightly longer initialization time. I will investigate this.

Mike

[itsme]

How about storing the formatted key as string in the database? Only for ChordPro songs with a transpose value specified. It could be clearly specified when these entries have to be updated: for all ChordPro songs when the change in the database appears for the first time and when 'Chord Localisation' is changed. Maybe there are more conditions that I'm not aware of. And the respective formatted chord string has to be updated for individual songs, which is not time critical at all. This is the case, when the transpose value of a song is changed and when a new ChordPro song is imported. That seems pretty feasible for me.
As soon as these formatted keys are available in the database they could be displayed like any other database field.