EDIT to add: Also altered dominant chords, such as building a diatonic C7 into a C7(b9) would include a Db. Getting further afield, if you borrowed a Bbm into the key of F, you might approach the Bbm with a dominant 7(#5) chord, yielding an F7(#5) with a C#.
Lots of fun possibilities! :-)
Maddening! Let me explain: I'm making a program that pulls a midi file in and then displays a score, and apparently there is no solid rule that dictates that you should use either the one or the other and the context that might give a resolution may not even be there yet when you have to decide (because midi data can stream).
If you are speaking in terms of a single melodic line, it could be a fair compromise to display C# if your previous note was lower than the current note, or Db if your previous note was higher than the current note, as it is traditional to spell with sharps when ascending and with flats when descending.
If you are displaying a chord (or some other system of harmony; four staves of a string quartet or whatever), then you could make a reasonable guess based on the other concurrent pitches: if you have an A and an E, or an E and a G, then C# might make more sense than Db.
Again, I think looking ahead to the next note/chord would offer a stronger heuristic for judging enharmonic spelling, but even then ... it's hard to know for certain what the arranger intended. MIDI just isn't robust enough for that.
Whatever solution you come up with, THANK YOU for being thoughtful enough to try. Some software is comically lousy in this respect.
--
Another thought: if you are dealing mainly with live/streamed data (maybe interpreting a live performance?) you could very likely detect patterns based on previous notes played. You might not know the next notes, but if your program was paying attention, it could probably make an increasingly good guess what's coming next, and thus get better at guessing how to spell the notes.
That looks to me like a descending melodic line (D -> Db) but the score has it as C#.
The workflow I have is something like this:
mp3 -> wav -> midi -> score.
And I'd like that score to come out as closely matched to what went in on the far side so that you don't end up totally confused if you ever do see the score as the composer wrote it up.
> If you are displaying a chord (or some other system of harmony; four staves of a string quartet or whatever), then you could make a reasonable guess based on the other concurrent pitches: if you have an A and an E, or an E and a G, then C# might make more sense than Db.
I think that is the beginnings of a workable system.
So, when ascending -> sharps, when descending -> flats.
For chords make rules based on the key they are played in and look ahead at least until you have all the notes in this chord so you can decide which one will fit better.
Hm, maybe there is some body of music scores that could be used to figure out preference of composers depending on key/chord?
That would be a pretty large lookup table but likely still doable or maybe as a database table with the pitch numbers in the chord as an index and the preferred spelling as the data for each entry.
So for off-line I have a good chance of getting it right and for 'live' your history could help to figure it out, especially because pieces tend to repeat certain patterns and chords (but that might lead to extra confusion if it turns out you got it wrong a previous time).
Anyway, in minor keys you very often see the note below the tonic get raised. So for example, in D minor, the pitch C#/Db will pretty much always be C#. You also often see the note two below the tonic get raised.
I'd say a "descending melodic line" should continue past the note with an accidental, so D-C-B is a descending melodic line, for which you could make inferences about the C, but not necessarily the B. If it goes down and then immediately back up again, the note in between is (in my experience) more likely to be sharp than flat, and vice versa.
As another rule of thumb, it is somewhat uncommon to have two consecutive notes with the same letter, one of them with an accidental. For example, if you have a G#/Ab, and it follows or precedes an A-natural, it is probably a G#. If it follows or precedes a G-natural, it is probably Ab.
Of course, exceptions to all of the rules can be found. :)
In the first place, I strongly endorse everything tjr said.
Secondly, depending on what exactly you're trying to do, I would guess that you can afford to get it wrong occasionally. After all, it is "the same note" ("enharmonic" really, but on many instruments you would play it exactly the same). You're losing a bit of interpretation, but with anything autogenerated from a MIDI file I wouldn't necessarily expect otherwise.
I've used such a software tool before -- I downloaded a bunch of MIDI files for Nintendo games I used to play, converted them to sheet music, looked at the sheet music, and tried a couple out on the piano.
Something else I might pay attention to is rhythm -- there are lots of "correct" ways to spell out any given rhythm, using a combination of notes, ties, dots, rests, and so on. But typically some of them are harder to read than others. This is something my software package did an iffy job on, which left room for improvement.
Sounds like a cool program!
For example, if you're using it in the context of a minor plagal cadence, Bbm to F (iv--I) then it's a Db because it's the minor third of Bb minor.
If you're transitioning from F to A7 (i.e. I--III7, common in jazz standards) then it'd be C# because that's the major third of A major.
In the case of jazz standards (and assorted other genres like Western popular music), melodies are often published alongside the author's intended accompanying chords, so when those are present they could maybe be used as a training set for an automated solution.
But for other genres, a ground truth label might exist only in the author's mind, or in the minds of sophisticated listeners familiar with that genre. Reasonable people might disagree about the fact of the matter in some cases (or shrug and say there is no fact of the matter and either option is okay). Sometimes when there's more emphasis on melody than harmony, the choice of C#/Db might come down to ease of reading (ascending notes B-C-Db might be easier to read than B-C-C#) rather than harmonic considerations. Or maybe as another commenter points out, the reverse convention might be used.
> An algorithm is probably impossible in the general case.
Ok, that's a clear answer. So, what I've settled on then is to take an educated guess and to allow the user to correct the software by annotating the midi file with extra hints about what the preferred spelling for a particular note is in case the software gets it wrong.
That way; assuming that I can get it 'right' algorithmically > 50% of the time it should still serve as a speedup and it will be flexible enough to fix things if required.
These could then be saved back somehow into the midi file as a json encoded text field along the lines of [{track, tick, pitch, preferred notation}] to persist the edits.
Thank you for all the thoughtful answers.
Ok, so let's say in combination with A would you use C# or Db? And more importantly, why?
There are exactly seven pitches in a tonality [0] (without getting esoteric), each named A-G. Whether a pitch is a C or D depends on whether that pitch is functioning as the C or D variant in the current tonality. The current tonality is not absolute, most interesting harmonies are created by changing it.
In major (one possible tonality) it is common to pivot to the parallel minor (another tonality that has the same set of pitches but different root). The baroque/classic way of doing that was by constructing the dominant chord of the destination tonality and pivoting to it. In F major, the parallel minor is D minor, whose dominant is A major, which has a C# as the third. If this is what your intent is in the composition, that pitch is named C#.
That's very hard to recover from random input though. But it may be possible to figure out if a piece is baroque/classical or more modern.
There's some interesting set theoretical approaches to this problem I can think of, but I don't think they'd be of use practically. There's a reason most notation software gets it "wrong" when transcribing MIDI data, because there are multiple interpretations of the same data and a limited set of them can be "correct" and I can think of cases where 3-4 of them are equally correct (by metric) but obviously wrong to a reader. Pedogical example is the "German" augmented 6th chord, which is specifically used as a pivot between tonalities and has four alternative spellings in the same key, and while a theorist will tell you only one is correct in context, in practice one may be chosen over the other (and I'd bet there are scores out there where the same pitch is spelled differently for different instruments).
Jazz isn't significantly different than baroque or classical. It's ordered chaos for the most part, and since it derives from blues will often fall into similar variations on familiar patterns harmonically. Notationally though, it can be all over the place, if it's notated at all. For example chord voicings are typically left as an exercise to the reader in Jazz, and early baroque, but left explicit in classical through to about the 1920s in art music where it has since diverged.
Deceptively tricky problem. Fun to think about though. If you're tackling it, like it sounds like you are, just remember that all notation is lossy and it's purpose is either to convey information to a reader or performer.
If you really want to get into the mind of it, study a bit of four voice harmony, counterpoint, and functional harmony. There's probably a lot on YouTube.
No kidding. Thank you very much for the thoughtful and concrete answer, I will do as you said, and go study the subject as much as I need to be able to get the bulk of the cases to reverse, I realize now that there won't be perfection but it should be possible to do it 'right' except in ambiguous cases, and there it might be possible to have the software indicate which notes have ambiguous representations in the score and give the user to choose the one they feel is right (to annotate the recovered data).
That should eventually cover all cases that are of interest.