Diatonic Transposition: new feature can be tested from Github

• Nov 15, 2012 - 20:29


I posted yesterday in the github repo a pull request adding an option for diatonic transposition to the current Transposition dialogue box.

It is NOT merged in the main code (even less in the nightlies) yet, but anybody with a working MuseScore development setup wanting to give it a try is welcome! This could help catching errors or things I may easily have overlooked.

In particular, I would appreciate feedback about the "Keep degrees alterations" option and the option for transposing diatonically chord names (I'm not even sure it makes any sense!!)




I'd like to test what you did, but I don't have the development set. I'm more of a plugin writer. I wrote a plugin for diatonic transposition, which I really use a lot. But when I developed it, I found out that there are so many questions to be answered that you just can't say what a perfect diatonic transposition is. I ended up in the following:

  • The original note sequence, which is to be transposed, is treated as diatonic notes in some key. That means I ignored any accidentals. If the key was Eb and there was an A, I treated it as Ab.
  • The transposition is done to some given key (any of 15 keys, for instance F# and C# are distinguished from Gb and Db)
  • The user can select the target key to be either major, harmonic minor or melodic minor.

I wanted to ignore the accidentals, because they would anyhow cause more options for the user to select. I mean, if you have a melodic sequence with accidentals that alter the tones of the diatonic scale of the key, you can't just place same accidentals on the corresponding notes of the transposed sequence.

In the same way, diatonic transposing of chords sounds very strange. But interesting! My approach would be something like this:
In C major, you would have the following "diatonic chord scale": C, Dm, Em, F, G, Am, Bdim
The transposing would just shift back and forth along the scale. Any 7-chord would remain as a 7-chord though. F.i. the sequence C C7 F would transpose to Dm D7 G or Em E7 Am.
In A minor, you could have the following scales: Am, Bdim, C+, Dm, E, F, G#dim or Am, Bdim, C+, Dm, E, F#m7-5, G#dim.

The difficulty in diatonic transposing, either tones or chords, is determining the tonic. Accidentals in tones and using 7-chords is usually about subtle change of the tonic. You can set up any kind of logic rules for all that, but there are always situations, where the user would have wanted something else, still thinking it's a kind of diatonic transposition.

In reply to by jotti

Diatonic transposition has been merged in the main github repo since a while, so it should be in the nightlies.

We all agree that diatonic transposition has limits: you cannot take a fragment by, say, Schömberg, transpose it diatonically and expect to get any sensible result. Or, to quote an example by Marc, take the sequence D, D#, E and transpose it diatonically one degree up: there is no way you can fit three different notes between E and F. In general, no chromaticism will give sensible result if transposed diatonically.

But this is not a limitation of the algorithm, it is how our musical system works: there is no way around it, I believe.

On the other hand, I am working on a collection of more than 100 canons (XVII c.), in which diatonic transposition works very nicely in the great majority of the cases.

" if you have a melodic sequence with accidentals that alter the tones of the diatonic scale of the key, you can't just place same accidentals on the corresponding notes of the transposed sequence."

Sometime you cannot, sometime you can; it greatly depends on the kind of music; possibly, some statistics could be set up, but it also greatly depends on the kinds of music each user deals with. Also for this reason, the dlg box has a check box "Keep degree alterations".

If the user is after a diatonic transposition, we have to assume that, in most cases, he is dealing with a piece in which this process makes sense (with or without the check box checked is up to him to choose). The occasional misfit has to be accepted and corrected by hand (and if misfits are not occasional, then the tool is not appropriate, rather then wrong).

Think for instance of the use of progression in Baroque music: it is very common, but in most cases, being used to modulate, it is neither truly chromatic nor diatonic; however, a mechanical diatonic transposition in most cases approximates the intended result better, with usually only one (occasionally two) notes to correct, while a chromatic transposition by a second (major? minor?) would usually get most of the notes wrong.

No algorithm would compose, or transcribe, for the user (at least no algorithm which makes sense to include in current MuseScore), but choosing the appropriate tool may reduce trivial tasks and let concentrate on the 'real' job. Even if the tool is a bit simplistic and does not try to guess too much, this also makes it more easily predictable and then easier to select among several.

For the moment being, I wold leave aside discussing the transposition of chord names (or symbols) as the underlying framework is not working (not even for chromatic transposition).

Thanks for the comments!


In reply to by Miwarre

No algorithm would compose, or transcribe, for the user (at least no algorithm which makes sense to include in current MuseScore)
More like "No algorithm or function is meant and developed for composing for the user". But feel free to use them creatively. When I worked with my diatonic transposing plugin, I enjoyed very much what I could do with it. In no time I had written a song based on diatonic transposing of a theme. Think "Windmills of your Mind" by Michel Legrand. The distinction between an algorithm that actually composes and one that help me compose gets a bit vague. The tool made sequences that I wouldn't have guessed in advance. I listened to them and went "Ok, why not! Cool!".
A similar tool would be an inversion tool, which could make either a perfect inversion or a kind of diatonic inversion. Not to mention retrograde, augmentation and diminution.

In reply to by Miwarre

It surely depends on the key you're in. You get E, E#, F whose last two notes are enharmonic in C Major (no law against that) but distinct in G Major (i.e. to say the F in G Major is played as F#).

I didn't know diatonic transposition had been implemented in MuseScore. That might have kept me with you a little longer. I would like to see polymodal transposition implemented in MuseScore. That would tempt me back :).

Hi Miwarre, you asked me on IRC whether my pull request https://github.com/musescore/MuseScore/pull/214 to fix #7510: Up/Down arrows skip diatonic notes for some key signatures had any effect on this Diatonic Transposition feature.

I tried a few scenarios both with and without my commit, and behaviour appeared to be the same in both cases, so I don't think I've broken anything!

I checked the tpc functions you had changed in your commit, and none of them were ones that I touched.

I assume if "keep alterations" is unchecked, all the source notes have their alterations removed first, then just stepping along the diatonic scale the requested interval. That was what I observed, anyway.

I did notice one anomaly with "keep alterations" (there may be others I didn't find): In the key of Eb, when doing a diatonic transpose up a third, a Cb became an Ebb as expected, but it jumped down an octave at the same time.

It might be worth revisiting the logic for alterations sometime, and defining in a key-independent way exactly what should happen to each scale degree and alteration type (e.g. bb1, b1, 1, #1, ##1, bb2, b2, 2, #2, ##3, etc.) for each selected transposition interval. It should then be possible to come up with a formula or table of offsets that can just be applied to the tpc and pitch easily.

Do you still have an unanswered question? Please log in first to post your question.