[erhe]

Now that I think about it, the test results could even be parsed into a 9261-entry lookup table and it would cover all possible transpositions of all possible notes, without having to even care about what the logic actually is. Unless you also want to transpose from/to double-flats, double-sharps etc.

[erhe]

So we can just change the logic to look at the key of the chord and if it is a sharp key, make the bass note sharp as well (and the same for flats)?

There is no "key of the chord". Chord symbols are not in a key. You do not have to have a key to play a chord, and an A major chord will be exactly the same regardless of what keys anyone is thinking or writing about. Atonal, keyless music can use chord symbols. What do you do if the song is keyless? Having a key or not does not matter.

And whether there are flats or sharps in a key signature, does not affect transposition of notes in any way. Because it does not matter if you even have a key signature to begin with. Note names in chord symbols are absolute, they do not depend on key or key signature, or the lack thereof. You do not even need to care about the fact that they are chords. 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.

[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 ?

[erhe]

To get A from Bb, you transposed down by a minor second, interval (-1, -1) for my transposition routine. Applying the same transposition to D yields C#. An interval of a second means that the letter changes by one position in the list of letters.

To get Db from D would be something like a "diminished unison", (0, -1).

I don't understand what you mean by "signature corresponding to the chord". When transposing slash chords, you perform the same process to both sides of the slash. The bass note is its own independent entity, when in comes to transposing. The transposing of what's on the right side is in no way affected by what is on the left side. If the bass note made sense in the untransposed version, but not in the transposed one, then you messed up the transposing somehow.

[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.  )

[erhe]

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).

Scales of chords, whatever that means in the first place, must not be looked at in transposing a whole piece. Transposing must preserve all inter-note relationships, however nonsensical they are. Transposing must not try to re-write or re-consider what there was in the untransposed version.

When you write things yourself, then of course you take many things into consideration, but transposing must be a mechanical, transparent operation without trying to re-write and fix potential mistakes.

If someone has indeed written something weird like "A/Db" or "G#/Gb" or similar bizarre things, for whatever reason, transposition must keep the weirdness intact and not try to be smart.

Let's take "G#/Gb" as an example of a deliberately hard-to-understand chord symbol. But we do not need to understand it. We only transpose it, we perform a mechanical operation that does not require any kind of understanding or trying to make sense out of nonsense. Let's say the key of the song has been marked as Cb, and we wanto to transpose it to A#.

INPUT INTERVAL: The interval from Cb to A# is (-2, -1). The letter changes from C to A, which means a letter change of -2. Chromatically, it is a change of one semitone, -1.

INPUT NOTES: In the chord symbol "G#/Gb", we have two named notes to transpose: "G#" and "Gb". 

First, transpose G# from Cb to A# i.e. (-2, -1). First, we apply the letter change: from G to E. Then we calculate: what kind of E note is it that's 1 semitone below G#? It is: E###, E triple-sharp.

Then, transpose Gb from Cb to A# i.e. (-2, -1). First, we apply the same letter change: from G to E. Then we calculate: what kind of E note is it that's 1 semitone below Gb? It is: E#, E sharp.

Now we have the note names transposed and we can put together the whole chord symbol.

OUTPUT: "E###/E#".

It is an E triple-sharp, with an E sharp in the bass. It makes just as much sense as the original untransposed nonsense, but we were able to transpose it mechanically, without trying to understand what it "meant" in the original untransposed version. Whatever it meant in the untransposed song, it means the same thing in the transposed version, relative to the new transposed key center. The relative letter name distances are the same, and the relative chromatic pitch distances are the same.

Correction: actually the Python program I posted calculates the interval from Cb to A# as (5, 11), which is effectively the same thing, just wrapped around to the positive side.

[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