[sciurius]

Good work, @erhe, thanks for providing these excellent reference materials.

I think that in case of MobileSheets and ChordPro, the much simpler yet effective approach that Mike mentioned in #14 will suffice.

Note that there is a difference between key transpose, and interval (semitones) transpose. ChordPro uses semitones transposition. This means that it is not possible to transpose from e.g. F# to Gb since the interval is zero. You can, however transpose from F# to G and then from G to Gb. But that is different matter.

[sciurius]

There is no "key of the chord"

It is just a way of saying that the bass notes should be named according to the signature corresponding to the chord.

[sciurius]

You take every note name one by one, whether it is on the left or right side of a slash, and transpose each of them by the exact same interval and the exact same logic throughout the piece.

That's even easier ☺. So you're happy with Bb/D → A/Db ?

[sciurius]

Let's see if I can follow.

To get A from Bb, you transposed down by a minor second,

Yes, a minor second = one interval.

Applying the same transposition to D yields C#.

One interval lower than D is the note between C and D, which is Db or C#, depending on the scale.

Since we do not take key signatures into account, I'm inclined to call this Db. What musical rule says it should be called C# ?

[BRX]

I'm just talking from the end users perspective, but as a pianist often working form the chords I just want to say A/Db feels wrong to me in any circumstance.

I don't think you can or should disregard the "key signature" or rather scale of the chord. If it becomes an A by way of transposing or otherwise the root/slash chords should be from the scale of the new chord (so always a C# for the A chord, never a Db).

[Skip]

I think normal convention is to use sharps for all notes/chords based (rooted) on natural (A>G) and sharp scales (A#>G#) and flats on notes/chords based on flat scales (Ab>Gb). That suggests the key of the 'too' scale controls the construction of the transposed chord. In the case of a 'keyless' 'from', the construction of the chord suggests the key type. With a keyless 'too', I suppose that would depend on the user with the restriction of 'one or the other' for the complete tune.

A mechanical approach that may work is to make two circles of the chromatic scale spacing each note, separating the sharps and flats and natural notes equidistant (17 notes). Make one circle smaller to fit inside the larger one. The smaller one will rotate inside the larger. The outer is the 'from', the inner is the 'too'. This will result in a straight one to one relationship.
G to A transposition---G>A, G#>A#, Ab>Bb, A>B, A#>C, Bb>C#, etc.

[sciurius]

A mechanical approach that may work

If I understand @ehre's algorithm correctly, that is precisely the approach he proposes.

[BRX]

On a (marginally) related note, maybe the transpose function could be enhanced to offer also an enharmonic change (don't know if it's called this way in English), so you can "transpose" from Gb to F# and so on. Probably almost no one will ever change a C to B# but you never know with some modern classical compositions, but I often see guitarists prefer the # keys and others the flat ones, at least for keys like C# and Db and F# and Gb.

P.S. I just thought about an exception that if a chord or root can be displayed as chord or root without an accidental than this should have priority over the one with an accidental (always C, E or F and not B#, Fb or E#) for readibilty and simplicity. (Again, just an end-user here).

[Skip]

Sharp to flat transposition and  rootless chords would still be one to one so the mech solution will work on them also. Sharp/flat consistency in rootless transpositions would be dependant on other chords in the tune.  

The transpositions I'm not so sure about are double sharp/flats.

IMHO trying to transpose using anything more complicated, as described in earlier posts. is not worth the effort. The simple fact is we're already past that leval of detail, we 're using diatonic scales, the 'other' stuff has already been done. (Sorry Mike.  )

[itsme]

IMHO there's no need to complicate transposing as proposed here. There's a huge community of MobileSheets users and in the ChordPro forum that is quite happy with the transposing method as it exists. With the exception that transposing in the text editor needs to be fixed to allow modifying the (very rare in my experience) cases where specifying usage of flats or sharps at song level is not sufficient.

[Zubersoft]

erhe - the one thing I'm unsure about is what you are proposing from a UI perspective here. All of your examples and the script are taking two inputs for every chord you have transposed, but does that mean the UI should be asking for two separate inputs as well? Your algorithm asks for a letter offset as well as a semitone offset - does that mean I would then be applying those same offsets to every chord in the entire song? Is that what most users would expect when using a transpose feature? I have been displaying the transpose as being key-based, but in reality, as you have mentioned, it's just doing it based on intervals (similar to the {transpose: #} directive with ChordPro) with extra (incorrect) logic for accidentals. 

It sounds like I can just use the mechnical approach mentioned above and just get rid of a lot of what is in the transpose UI at the moment, and just have it based on an interval/number. Seems like trying to track the original key of the song and displaying the key to transpose to is unnecessary as I'm not really using that information (at least not in a correct manner) under the hood.

Mike

[itsme]

I admit I have not completely understood what "letter offset" is good for. It seems that this is complicating things as E - F is a distance of one semitone, F - G is a distance of two semitones. The consequence is that transposing needs to be specified with two values like (-1 -2). Does that really work as intended for all chords in a song?

Assumption: we are in the world of "well-tempered" music where e.g. f# and gb are considered the same tone.

By now in any case I came across, one "distance" value specifies transposing (Finale, MuseScore, EasyABC, MobileSheets, ChordPro Reference Implementation). There's transposing "by key" or "by semitone". Both can be thought of being based on a closed circle with 12 positions like a clock. "by key" uses the circle of fifths. "by semitone" uses c c# d d# e f f# g g# a a# b (or its equivalent written with flats). Transposing goes the same number of steps to the left or to the right for every key or note. Both approaches lead to the same result.

Open question: shall the tone or key be written using flats or sharps.
There are conventions if flats or sharps shall be used. That's for better readybility. Music theory, music notation, personal preferences - these three might be slightly different. Keys and chords are seen as "flat" or "sharp" by most musicians, based on the main scale of the base tone. Ab is "flat", G# is "sharp". It is common to avoid mixing sharps and flat and it is common to write the bass tone of slash chords so that it matches the chord, e.g. A/C# is the normal way, A/Db is very unusual as A is a "sharp" chord a c# e, being the tonic of the key A with three sharps, the IV of key E with 4 sharps or the V of key D with 2 sharps.

There's a limitation of the current UI: the flat / sharp buttons allow specifying to use flats or sharps only for the whole song. This is sufficient for a lot of (most?) cases. I meet the limitations sometimes with songs in minor keys when I want to write down bass notes. 
Example: a simple I IV V I in minor Am Dm E7 Am. I add a bass run Am/E Dm/F E7/G# Am/A
Transposing results are not nice (only) for certain keys:
Dm/A Gm/Bb A7/Db Dm/D should better be Dm/A Gm/Bb A7/C# Dm/D
Gm/D Cm/Eb D7/Gb Gm/G should better be Gm/D Cm/Eb D7/F# Gm/G
This is a constructed example, "Yesterday" by the Beatles as mentioned before is another one.

In my practical use songs where I need a destination key to which I cannot transpose nicely happen rarely. In these cases I would use a workaround: make a copy, transpose it in the text editor (supposed the reported issues are fixed) and edit manually what I want to be different.

[itsme]

The chords of "Yesterday" as they are written down in Realbook 6th Edition.
I can transpose it to all 12 keys and everything looks fine - not too bad, I think.

[sciurius]

The main difference is that @ehre is transposing keys, while we are transposing intervals.

When transposing intervals, the result of D one interval down is ambiguous, it can be Db or C#.

Using the transposition rules for keys, the result of D when transposing from F to E is non-ambiguous: C#.

The result of D transposing from C# to C, also one interval down, would then be Db.

We would need to apply enharmonic equivalents, otherwise Ab transposing from C# to C would become Abb. In the real of well-tempered tunings we call this G,

[Skip]

It looks, to me, like a comparison of apples/oranges (equal temperament/non-equal temperment). Being an equal temperament, hobbiest type, I would be unhappy with getting a transposition to double sharps/flats. Users of other temperments will probably feel differently.

https://www.cmuse.org/well-tempered-vs-equal-tempered/