CLI Transposition Enharmonic Spelling Optimization #26887
ernie-bird
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This probably could be an issue, but I'm not clear on how to approach it yet.
I'm slowly building a tool for my work that allows me to transpose musical theatre scores through the command line in bulk. (I also plan to integrate that with Python scripts with Xonsh, but that’s a much later project.)
I work at a major theatre licensing company, receiving many transposition requests, and my dream workflow would be straightforward:
In theatre, I frequently work with scores that change keys—sometimes multiple times within a piece. This is where I’ve encountered a challenge.
I’ve attached dummy piano-vocal (PV) PDFs of Sondheim’s The Worst Pies in London from Sweeny Todd to illustrate the issue.
Original:
worst_pies.pdf
Transposed:
worst_pies-tr.pdf
Here's the bash command I used:
mscore worst_pies.mscz --score-transpose '{"mode": "by_interval", "direction": "up", "transposeInterval": 3, "transposeKeySignatures": true}' | extract worst_pies-tr.mscz worst_pies-tr.pdf
("extract" is an extract.py tool that builds mscz from json)
MuseScore offers many transposition intervals, but since I work in the + and - semitone "universe", I THOUGHT I only needed these:
+1 = Minor Second (3)
+2 = Major Second (4)
+3 = Minor Third (7)
+4 = Major Third (8)
+5 = Perfect Fourth (11)
+6 = Augmented Fourth / Diminished Fifth (Tritone) (12)
...and similarly for -1, -2, etc.
When I need +1, and therefore use "3" (Minor Second), I expect all keys to change accordingly—for example, A to Bb, and Gb in bar 13 to G. And they do just that. However, starting in bar 13, the notes have incorrect enharmonics. I sort of see what the problem is... Using "1" (Augmented Unison) transposes enharmonically correctly only for that Gb>G region (as it should, according to music theory) while creating a mess elsewhere (as it also should...). And I could certainly fix the spelling by opening the GUI, transposing the regions, or respelling everything, but there probably has to be an easier way I'm not aware of, or it doesn't exist. And if it doesn't, I thought of possible solutions:
1. "Optimize enharmonic spelling" inside the transposition tool
In the Change by Interval and Change by Key options, there could be a checkbox: "optimize enharmonic spelling", which already exists as a standalone. This feature could also be added to the
--transpose-score
CLI command as an option. (And it would maybe adjust the score pre-output?). (It would somewhat clash with the idea of having 25 intervals and centuries of music theory, so potentially controversial...)2. A separate CLI command for "optimize enharmonic spelling"
There could be a standalone CLI command like
--optimize-enharmonic-spelling
for the standalone tool that already exists. This would allow post-processing of an already transposed score. (This could be useful regardless)3. Transpose by semitones
Another approach could be introducing a whole new transposition method: "Transpose by Semitones." This would optimize enharmonic spelling automatically for users who are less well-versed in knowing when to use augmented unisons vs. minor seconds for correct enharmonic preservation, and would handle scores with multiple keys well. It would change all the keys, and put all the notes where they belong, in one click! And "by_semitone" would also become an option for the
--transpose-score
command.I think it would be interesting to start a discussion and explore which of these solutions (or a new one) makes the most sense. I can then create an issue. I'm very new to software development, but I'm eager to contribute once I gain more clarity.
Here are the .mscz files for anyone who needs them.
worst_pies.zip
Beta Was this translation helpful? Give feedback.
All reactions