[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Denemo-devel] Checking for wrong enharmonics (e.g C# for Db)
From: |
Richard Shann |
Subject: |
Re: [Denemo-devel] Checking for wrong enharmonics (e.g C# for Db) |
Date: |
Mon, 11 Jul 2011 11:35:29 +0100 |
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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/denemo-devel