denemo-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]