4 ms·

Obviously nothing native to the key, but various borrowed chords and what-not, such as: a V-I tritone substitution of Gb to F would include a Db; augmented 6th

by tjr 6y ago

Obviously nothing native to the key, but various borrowed chords and what-not, such as: a V-I tritone substitution of Gb to F would include a Db; augmented 6th chords, such as German or Italian 6ths, built off of Db directly; a borrowed dominant leading to Dm (A7) would include a C#. 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! :-)

jacquesm 6y ago
Thank you for answering. 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).
- tjr 6y ago
  Without looking ahead to see what's next, I would agree, there's no solid way to determine if the pitch should be displayed as C# or Db. 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.
  - jacquesm 6y ago
    Here is an example: https://youtu.be/o_wsSIuv_po?t=21 https://youtu.be/o_wsSIuv_po?t=21 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).
    - impendia 6y ago
      This particular piece is in D minor. (You will definitely want your program to figure this out; otherwise you will produce the "wrong" key signature, need to include a ton of accidentals, and it will look a bit kludgy.) 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. :)
- impendia 6y ago
  Amateur early-intermediate level pianist here. 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!

by tjr 6y ago

jacquesm 6y ago

Thank you for answering. 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).

tjr 6y ago
Without looking ahead to see what's next, I would agree, there's no solid way to determine if the pitch should be displayed as C# or Db. 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.
- jacquesm 6y ago
  Here is an example: https://youtu.be/o_wsSIuv_po?t=21 https://youtu.be/o_wsSIuv_po?t=21 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).
  - impendia 6y ago
    This particular piece is in D minor. (You will definitely want your program to figure this out; otherwise you will produce the "wrong" key signature, need to include a ton of accidentals, and it will look a bit kludgy.) 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. :)
impendia 6y ago
Amateur early-intermediate level pianist here. 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!