Thinking about it, what I can do with your algorithm is really cool - on MIDI note entry I can check what interval is formed with the last entered note and play it in a distinctive manner if it is unusual. The user does not even need to look up if they know they have just played an augmented sixth rather than a minor seventh. (I confess to not having studied the algorithm in any detail - too impatient :( but I have confidence in you :) Thanks Richard
On Mon, 2011-07-11 at 08:35 +0100, Richard Shann wrote: > 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 > > > > > > _______________________________________________ > Denemo-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/denemo-devel _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
