Transpose in Set

[Alistair Baty]

Hi Gareth,

Transposing and saving the key specific to a Set is fantastic.

Some of the always I really like:

• Clicking on the Song in the set produces the Key for that set
• Clicking on the same sign, but from the song list menu will open it on the original (or my default) key. (PS. I think you could rename that entry to Default Key, as it does not have to be the actually Original Key, but rather what one chooses as default)
  
• It no longer saves the (different key than original) in the Set. I confess it has been some time that I have updated the new version, so I don't know when that was changed. But it helps keep the set file clean and simple. I also found if you edit too quickly it crashed the Set file as I assume it tried to write over a half written copy)
  
• Editing the (deferent key) song opens the original so that changes or fixes are apply to the original song and you don't have to fix things twice. This aligns with the philosophy that this is not a variation.
  
• However, I am finding the changes are not automatically refreshed in the "different key" file. Even if I go to another self and back to the "different key" song. I have to remove the song from the Set and add it again to refresh the Cached copy.
  
• I also find that, there are situations, where if you open the App, and the last sing you had open was a "different key" sing it tries to open the song from /variations/cache and fails, with the error "this song has been removed". (This certainly occurred after I just updated the App.)
  

I would like to suggest the following:

Instead of saving the "different key" song temporarily in the /variations/cache folder, just transpose the Original file to the key saved in the Set

• If the song is opened from the Set List, check and if necessary transpose it to the Set key.
  
• If the song is opened from the Song List, check and if necessary transpose it to the Original key. Once a sing is in a Set chances are very good the key will not change again until after the Set is practiced and played. (There is a case to be made if this is really necessary. If you have it is a Set why do you want to change it to a different albeit the original key?)
  
• In both cases the Key metadata is updated Original Key metadata is never changed.
• The Song List always show the Original Key, While the Set List always shows the Key in the Set file. So the Key metadata is only used in the key Check process: e.g. if it matches the Set key, no transpose of you clicked on the set list entry.
  

This has the following advantages:

• Transposing is so fast - probably faster than writing the temporary file to the /variations/cache folder. As noted above, it is unlikely that you will change the key after you have added it in and are preparing to play a Set.
  
• It avoids the error of not finding a cached song on App startup.
  
• Editing the song will be in the "current key" - whether Original or Set keys - so you don't have to think in a different key to what to are playing in, like you currently must do. (I need to change the C chord to a M7 , which is an A chord on the original.)
  
• Changes will reflect immediately in the song in the Set key. (Which will be faster than if you add code to refresh and rewrite the cached copy after an edit.
  
• Sharing a Song will be in the Key you are currently playing it on, and keep it on the normal file name and not with the affix "_K-key", so the musician can save it in the Main folder. (I think the import process might address the File Name and song Title anyway, so this might not be a benefit)

Just some thoughts. There may be other reasons for not transposing on the Original file, I'd  be interested to know what they are.

Thanks again,

Alistair

[Gareth Evans]

Hi Alistair,

Thanks for your thoughts! I'll explain my thinking behind the key/set keys/etc.

I think you know these, but added here for others reading:

• Variation - a copy of a song that is embedded into a set.  This file can be edited, transposed and ultimately embedded in the set file (as a custom item).  When the set is loaded, the variation file is extracted from the set file and saved to the /Variations/ folder.
• Temporary variation (key change required for a set item) - a temporary copy of a song that is purely transposed to match the key of the set.  It isn't saved to the set other than keeping a note of the key it should be in.  When the item is first viewed, a temporary files is created in the /Variations/_cache/ folder.  You can't edit this file as it is purely a key changed copy of the original.  Because this is a temporary variation, any edits are made on the original song and the temporary variation should be created again with the transposed chords - it sounds like this isn't happening though?  If you want to edit lyrics, this will change the original.  This is where a standard variation should be used.
• The original key is designed to be a reminder of the key the song was originally in (e.g. when recorded, or when you first create it).  This doesn't change and can be used to quickly transpose a song back to this key if required.
  
• The key (preferred/default key) is the key the song file is saved as.  This is the default key that is used when creating new sets, or when displaying the song outwith a set.

Why the need for different keys in sets?  I play in several different bands and they play many of the same songs, but in different keys - sometimes to make it easier for the guitarist, the singer, or just because they want to.  I keep the original file as my default key.  I don't want to keep manually changing back this songs, so when I load up a set for that band gig, the set keeps a record of which key I should be using and when I call up the song in that set, it shows me it in the key I need.  If that is the same as the original key, it just displays the original song, otherwise it makes a temporary variation (not a normal variation that gets saved with the set) and saves it to the /Variations/_cache/ folder and puts this into the correct key.  When I'm not playing in those bands and I'm skimming through songs to play, I expect to see the key as my preferred one.  I try to avoid overwriting the original song wherever possible.

I often use the original key to remind me of the recording key, even if I never actually use that key.  This is probably the only reason that I not sold on having a song revert back to the original key when viewing it when it isn't in a set.  I never want to see it in that key, just know for reference that the recording is different!

Firstly it sounds like I need to check in on the temporary variations not being updated properly.  I created these temporary files as creating them once then loading them is quicker than transposing every time in the background, particularly for larger songs.  If the file exists, use it. If not, create it then use it.  I wonder if the edit isn't overwriting that temporary file properly.

Also, it might make sense for me to offer the option when editing the temporary key changed song, to allow the song edit to be shown with either the key changed chords or the original chords.  The save should be made to the original, but with the preferred key (specified in the song, requiring a transpose) and a fresh temporary variation created as well.  i.e. edit original song in the preferred/default key or edit original song while displaying the key used for this set.

Does that make sense?

Gareth

[Alistair Baty]

Hi Gareth

I think having the keys saved per Set is one of the best things ever. Like you said we often pay the same songs in different bands where the lead singer wants it in"their" key. Up until the new OSA, I would keep track of Original Album key (and BPM) in the Sticky Note. I also record "My" key there so I don't forget. I will use the "Original" key to save "My" key - I like the ability to quickly revert/transpose back to that if the key in the song list ever changes. - I'll keep the original album key in the Sticky Note.

There may be an issue with the refresh on the Set "key" as well I noticed it also does not capture a second key change. In other words if I transpose the original it asks whether to make the change in the Set, and saves a temporary Variation file with the affix that reflects the Set key. But if we decide to charge the key again, it will do so with the temporary file correctly, but does not update the Set list too show the new revised key. The temporary Variation file name doesn't change, but that probably does not matter. (The second transpose seemed to break the Set list as well as it kept telling me I was looking at the last song in the Set, but a could not go back or forwards from any song in the Set)

The main issue for me is that I lose all my highlight notes on the song when I use a Set key - a bit of a show stopper. This is no problem if I simply transpose the original file. I tried creating a copy of the highlight png file and changing the name to try match the new location, but that didn't register. This is another case where the option of "automatically" transposing the original, rather than creating a temporary Variation, would keep using the original highlights and facilitate any edits to the highlights as well. But I understand that is not how you are configuring and sequencing the Set key features.

Thanks

ALISTAIR

[Gareth Evans]

Hi Alistair,

I'm reworking the key variation logic to try and address the issues you are seeing.

• I think I've got updates to the original reflected in the key variation file
• Any highlighter notes saved with the original song will now also show with key variation files
• Updates when transposing songs update in the set

I've a few more tests to run to check I haven't inadvertently broken anything else, but expect an update this week (v6.1.6)

Best wishes,

Gareth