Re: [Denemo-devel] Checking for wrong enharmonics (e.g C# for Db)

[Richard Shann]

Thanks for this. Yesterday I did more digging around and found a paper
by Jerome Barthélemy &al Figured Bass and Tonality Recognition, which
went well beyond what I was looking for. And then I discovered that the
keyword is "Pitch Spelling", obvious when I think about it, people would
have been trying to do this for turning MIDI files into notation. In
this connection I found stuff like David Meredith, Pitch Spelling
Algorithms and Joshua Stoddard &al WELL-TEMPERED SPELLING:A
KEY-INVARIANT PITCH SPELLING ALGORITHM. 
One of these papers reported finding more errors in the original
documents than errors made by the algorithm!
But so far no actual code I could call, and the algorithms look fairly
heavy. Having realized that anyone trying to do MIDI->Notation will be
wanting to do this, I was thinking some more digging may be worth while
looking under MIDI->Notation converters. Your idea would be much quicker
both to implement and execute, and could be enough for my purposes.
I'll do a bit more digging...
Richard
BTW I did a bit of re-working of your ReBar script; I hope I used the
latest version, as I couldn't locate (all?) the bug reports where you
submitted it - I used the version in git.




On Sun, 2011-07-10 at 20:03 -0400, Daniel Wilckens wrote:
> Hi Richard,
> 
> I've only had time to look at the mailing list every once in a while 
> recently but I did see your post asking for an algorithm to check for 
> misspelled enharmonics.  This could be tough, as e.g. dimished fourths 
> would be rare but not forbidden.  Here are a few thoughts of mine on 
> this, though you probably already considered something along these 
> lines.  Unless you want to go with something really fancy AI-wise, I'd 
> probably go with an interactive script that stepped through the score 
> looking for unlikely interval spellings in consecutive notes  (that 
> would be diminished fourths like D to A#, augmented seconds like C to 
> D#, augmented thirds, diminished thirds, etc.) and ask you to decide 
> whether you really meant it to be written that way or whether you want 
> the script to fix it for you to the other spelling.
> 
> To sketch an algorithm for this, each pitch-spelling would be given an 
> integer (which I'll call its index) representing its distance in number 
> of perfect 5ths from C.  So, C would be 0, G would be 1, F would be -1, 
> .. C# would be 7 and Db would be -5, etc...  Then the script would flag 
> something as unlikely if the index of consecutive notes differed by more 
> than 6 (6, being a tritone, could go either way: C to F# or C to Gflat 
> are both OK).  This is a pretty feeble-minded AI but should catch most 
> errors of the sort you'd encounter I would think.
> 
> For individual chords, you could check if the set of indices of the 
> tones comprising the chord fit into a set of 6 consecutive integers, i.e.
> 
> | MinIndex-MaxIndex | <= 6.
> 
> So a D7 chord, D, F#, A , C, would translate as the indices 2, 6, 3, 0, 
> which easily fits into the set 0, ... 6, so it's OK.  (This would 
> wrongly flag augmented 6th chords, since Aflat to F# would be indices -4 
> and 6, which is an interval of 10.  That's one reason to require the 
> user to check each proposed fix.  Augmented chords would be flagged 
> also, but probably the user can deal with each one since they're not all 
> that common until later.)  Consecutive chords should be flagged as 
> suspicious, I would say, if their combined set of pitches has  | Min - 
> Max | of 9 or more, since a cadence in a minor key involve the third of 
> the dominant and the third of the root which have an interval of 
> diminished fourth.  These tolerances could be tweakable.
> 
> I can't even think of any plausible fancier algorithm.  Somehow you 
> could take into consideration not just the current and preceding 
> note/chord, but perhaps the next one also.  There are some methods out 
> there that might be worth looking into if you were really gung-ho, like 
> Hidden Markov Models which some people have tried to write automatic 
> piano-fingering generators with, but they take a lot of tweaking and 
> "learning".  Hope this helps!
> 
> -Dan
>