search

thebigg73 / OpenSongTablet

Android port of OpenSong. Use your mobile device as a portable song book. Gareth Evans
GNU General Public License v3.0
32 stars 23 forks source link

v6 Transpose in set (or variation) doesn't match highlighter file #224

Closed thebigg73 closed 11 months ago

thebigg73 commented 1 year ago

Need to not use the actual folder (**Variation) but the original one when looking for the highlighter file

iv-gha commented 1 year ago

It is a new song based on the original. It should perhaps copy original highlighter files just as it copies the original song file. The end result being a separate song with separate files.

thebigg73 commented 1 year ago

The variation isn't a permanent file though and the highlighter isn't included in the set file. If the song filename is the same, it should just use the same notes. Expecting different notes might confuse the issue for users using song in a set which is purely a temporarily transposed version that calls the user song file and ad hoc translates it (full variations perhaps differently). I've put a fix in place for looking up the original highlighter file. If the user saves the variation as a new song, it will then get a new blank highlighter file (as it will have a different name). If the song is being changed for content as in a full variation, the old highlighter file would be obsolete anyway as the positioning would change.

v5 didn't do any of this with highlighter notes and nobody complained, so I think this is a sensible way forward that most won't even notice! The set item variation in the most part was used to transpose a song into a different key (without needing to change lyrics, etc). The new set key option makes this simpler and removes the need for a full variation for most people. This way any changes in the highlighter notes are reflected whatever the new set key is.

Happy to reconsider a copy of the highlighter, but we'd need to figure out a way of keeping those files in check as you could quite quickly end up with lots of orphaned highlighter files.

iv-gha commented 1 year ago

I think linking to highlighter files for a song in a set with a key override is valid. As you say the song is obtained from the users original with auto transpose - makes good sense.

However, variations (a song in the set which is added to the variations folder) should not - we do not know where it originated. So please do not code it for variations.

Variations (Song embedded in a set) have many uses - they need to be retained.

A great use for variations is to capture songs (receive host song) when using connect as variations into a set. A leader will share and step through their set, a client then adds them as variations to a set. Clients end up with a set of songs the host has with no impact to or reliance upon their song library. Great.

Users who share sets can share as a set containing variations. This again places no demand on a client to have a song or to have it as the host has it. The songs are in the set and unpack into the variations folder. Delete the set - they are gone.

For me variations should not have highlights.

We perhaps need a separate term for songs in a set with a key adjustment? I get easily confused.

thebigg73 commented 1 year ago

This is the case. Variations do not get access to existing highlighter files, unless they are set item key adjustments only. Standard variation files get the matching file name of the song in the 'Variations' folder. Because variation files that are 'set key adjustment files' have the filename prepended with the folder name (e.g. MAIN_) they can look up the matching highlighter file. Standard variation files don't have a 'memory' of the folder they came from, so can't look up a variation.

On Fri, 14 Apr 2023 at 19:15, iv-gha @.***> wrote:

I think linking to highlighter files for a song in a set with a key override is valid. As you say the song is obtained from the users original with auto transpose - makes good sense.

However, variations (a song in the set which is added to the variations folder) should not - we do not know where it originated. So please do not code it for variations.

Variations (Song embedded in a set) have many uses - they need to be retained.

A great use for variations is to capture songs (receive host song) when using connect as variations into a set. A leader will share and step through their set, a client then adds them as variations to a set. Clients end up with a set of songs the host has with no impact to or reliance upon their song library. Great.

Users who share sets can share as a set containing variations. This again places no demand on a client to have a song or to have it as the host has it. The songs are in the set and unpack into the variations folder. Delete the set - they are gone.

For me variations should not have highlights.

We perhaps need a separate term for songs in a set with a key adjustment? I get easily confused.

— Reply to this email directly, view it on GitHub https://github.com/thebigg73/OpenSongTablet/issues/224#issuecomment-1509046796, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3X52X3U2EA4TD5CGMB77DXBGH4DANCNFSM6AAAAAAW5UNM5A . You are receiving this because you were assigned.Message ID: @.***>