Automatic Fingering Prediction 0.1ish

TonE · Post by **TonE** » 07-25-09 1:50 am

: Palmer Altenmuller; Palmer Altenmueller.jpg (169.26 KiB) Viewed 30886 times

No comment.

Post by **Nicholas** » 07-25-09 2:45 am

!!

Where did you get that?!

Those are the graphs I'd always dreamed about...

TonE · Post by **TonE** » 07-25-09 8:20 am

Nicholas wrote:Where did you get that?!

I got it from the pdf document with the title: "Nature of memory for music performance skills" by Caroline Palmer, McGill University, Dept of Psychology, here.

Actually I did not read everything there, but liked those pictures a lot. There it says on page 30: "Figure 2. Pianist’s fifth finger height above keyboard in terms of position (top panel), velocity (middle panel), and acceleration (bottom panel) during a single performance of the melody shown at top, at a moderate tempo (bpm = 120). Vertical lines indicate time of each keypress (as recorded on MIDI keyboard). "

This pdf documents says further on page 18:

Palmer and Dalla Bella (2004) measured anticipatory movements in piano performance of simple melodies performed at a range of specified tempi. Pianists’ finger motions were recorded with a Vicon-8 system with passive 3mm markers placed on a pianist’s right hand, as shown in Figure 1, and 14 cameras placed around the pianist recorded light reflected from the markers.

I wanted to add it here mainly as a mind opening/refreshing input to consider more detailed distance measures for the fingering difficulty calculations, at least in future, e.g. using mm, instead of half-tones, additionally considering the height difference between white and black keys, considering the depth difference between white and black keys, also that fingers move into the keyboard sometimes for certain finger positioning, which we could define as the z-axis, if pitch/key is x-axis, height is y-axis (representing finally velocity, not pressing the key equals to velocity=0, no sound output, pressing the key with some velocity results in sound output with its loudness usually proportional to its velocity).

The paper "An Ergonomic Model of Keyboard Fingering for Melodic Fragments" of Parncutt writes already on page 6 in the footnotes:

8. An octave on a modern keyboard spans about 165 mm, so the average size of chromatic
intervals may be calculated on the basis of about 13.7 mm per semitone. A future
version of the model might benefit by representing distances between fingers in millimeters
instead of semitones and comparing them with distances on the keyboard between specific
keys, also expressed in millimeters.

vicentefer31 · Post by **vicentefer31** » 07-25-09 4:37 pm

A comment: When you play a song, very often some measures are played several times in differents place of the song, so those measures should be played with the same fingerings. How is going to do that this software?

Edit:
Before Nicholas made a software for have the note number of the midis I did a mbd with the 5 first hanon exercises with the notes and the finger, but nobody has download

So, I post again. I think it can be useful.

TonE · Post by **TonE** » 07-25-09 6:11 pm

Thanks vicentefer31, I saved it as .txt files, separately for each exercise, so in the attachment you find 5 .txt files of the first 5 Hanon exercises which you prepared as .mdb.

Frost · Post by **Frost** » 07-25-09 7:24 pm

Thanks everyone, for all of your input. The next version (loads midi files, has correct note names, shows how each parameter affects the scoring for easy debugging, compares different fingers to find how similar they are, more refined rules, better gui..) should be ready in 3-7 days.
For the next stage after that, actually refining the fingerings, I will need a very high number of fingered pieces. Thanks vicentefer, for the hanons. The hanons, czernys, pieces with good fingering data available.. Whatever we can get. The songs should be for right hand, and with no overlapping notes (i.e. monophonic). Higher the song count, longer the piece the better (without repetitions of course. hanons can be regarded as quite short). We would need a minimum of 20-30 average length pieces; 100 would be a nice longer-term goal. So, if you can help in any way (actually preparing the notes/fingering data, finding sheet music with authorative fingering, or even suggesting the name of your favourite pieces with "nice" fingering if you are low on time), I would appreciate it.

Frost · Post by **Frost** » 07-25-09 7:30 pm

this post has technical discussions, ignore if you are uninterested.

1. A growing set of reference .mid files with "perfect" or official fingering for each note in that piece from various sources, e.g. Czerny, Hanon and more. The fingering information should be written into a separate .txt file, writing one finger number per line or continuous writing with spaces in between as it is the case in your AFP. This "testing set of phrases/midi files" is important to evaluate the current algorithms performance based on input parameter changes into the algorithm/system.

yes, I was going to collect all possible hanon/czerny AND also quite a lot of actual piano repertuare with "correct" fingering to test data in batch. Few specific cases should be tested with the eye (I mean, "are scales played as 1-2-3-1-2-3-4-5" etc? advanced players/teachers can help in this manner, the *must*/*shall* cases), but other than that, seeing how much of the test data it captures accurately would be better than on-case basis; improving for one situation may worsen other situations, we won't see it otherwise.

Regarding finding the right values for the (hundreds of) parameters: isn't that what genetic algorithms are really good at doing?
If we had some larger body of samples with known fingerings, (I wonder if the Hanon set is a diverse enough training set just by itself), you could start doing the generational approach with parameter searching.

yes, that was what I was thinking of. crossover func. would be trivial for parameter optimization, but there are few problems, such as finding the similarity of two fingerings.
Simplest scoring function would be "+1 penalty for each mismatch", but if our fingering is "5 4 3"; the possible fingerings "4 3 2" and "1 4 3" would have same penalties but the first one is much better. A difference based one, or edit distance may be used, or taking the derivative (actually delta) of the notes, but that would under penalize the first one, so I was thinking of an affine mismatch penalty like thing. I thought of the algorithm, will try it. It would need modifications for polyphony though. And there is also the need for actually coding the GA

Anyway, I am thinking of doing that, but the main problem is the fingering data. We have gazillions of parameters. To actually find a really good parameter set that would be good for most of the inputs, we also would need hundred gazillions of test sets; hanon and czerny would be very limited.
But we can do those step by step. First the actual scoring parameters, there are about 30-40 of them (shown in the main screen). Finding their optimal values would be much easier. The ~100-200 finger reach/stretch scores may be deduced by, you know, actually looking at our hands

Parncutt paper also has a very nice table (minimum comfortable reach between finger pairs x-y, maximum comfortable.. also for min/max relaxed reach, practical reach) that they found by examining pianists, so that would be good enough for now I think.

For example so far I do not know yet what exactly you are using from the mentioned papers, where and how, to what degree, and always explaining why we have to use it? Maybe we can just ignore it, or maybe we have to detail it much more which was not done in the paper because of any reasons at that time like lack of time, lack of interest, lack of craziness, lack of original external idea inputs...

AFP uses *all* of them, and then some more. Parncutt and Jacobs are on the same monophonic model, which is the basis of the algorithm. Kasimi is used only to extend Parncutt into polyphony; the vertical cost part is used, and the logic of horizontal cost is applied to Parncutt.

For clarification, we have two main finger-to-finger parameters. One is stretch (pressing the keys at the same time) by Kasimi, and the other is transition (pressing the keys one after another), by Parncutt. Parncutt parameters are quite good as I said, so I'm reluctant to change those without any evidence why the alternative is better, maybe the genetic algorithm will change it.
the reason why I asked "Would you be interested in finding hand stretch scores between finger pairs? As the 2-5 example, but for all pairs ( 1-2, 1-3, 1-4, 1-5, 2-3, 2-4, 2-5, 3-4, 3-5 and 4-5)", was that, Kasimi paper does not give those values, only 2-5, and a low quality one, that looks like made-up without any backing evidence. Considering it's just a conference student paper, that lack of data may be expected, so, I don't have those parameters yet.

Or giving another example, until reading your question I did not know yet that no such information is used anywhere in the algorithm already or those papers did not answer this question yet in a sufficient way. The goal of this mentioned list in this point 2. would be exactly to prevent such situations.

Finger pair stretches are used in the algorithm, but since there are no "stretches" right now (we assume hand would stretch only if multiple keys are pressed at once, as in chords. finger-to-finger transition scores are different.), they are merely ignored.

2. A list of made assumptions and requirements for anything we use in the algorithm. Best would be having some sort of pseudo-code descriptions using natural language, and adding comments to that pseudo-code. Then any follower could see its use/location in the algorithm and why it is there, along with any requirements and limitations for that part only.

assumptions and limitations are in the first few posts. but you are right about the pseudocode, I'll write a guide about the method so other people can suggest ideas.

at least in future, e.g. using mm,
..
The paper "An Ergonomic Model of Keyboard Fingering for Melodic Fragments" of Parncutt writes already on page 6 in the footnotes:
An octave on a modern keyboard spans about 165 mm, so the average size of chromatic intervals may be calculated on the basis of about 13.7 mm per semitone.

We *do* use physical distance. Parncutt used semitones, Jacobs says that's naive, use physical distances (distance between C and C#, a semitone is not equal to E and F, also a semitone). I don't know why they did as they did, considering it's a very minor change. Well, we don't use the actual finger trajectory, just the horizontal line from key to key AND the vertical distance to black keys (for short fingers only right now), so no need to use milimeters. Our 1 unit distance is equal to 13.7mm, thus two consecutive white keys are 1 unit away, whereas consecutive white-black keys are 0.5 unit=6.85mm from each other. Of course we assume we hit the center of the key horizontally, which is mostly correct. However the vertical (not vertical, depth in actual sense, but depth makes more sense in pressing the key) distance may vary quite a lot.
The problem with the approach you mentioned would be, we would not be calculating just the fingering but the coordination; where exactly to press on the key and show it as well, also how the hand would move even when NOT pressing the key (i.e. hand and wrist motion) otherwise the additional calculation makes no sense. Basically, those are complications that do not carry any usable information (a good model that does not take hand trajectory into account and another model that does would basically give the same fingering), thus they are ignored, and, imo, they should be ignored. You can't get very far without building simplified models of reality, the extra information would be useless since >95% of the people will disregard the trajectory data and go with what is comfortable to them.

However, timing should be taken into account in the future (very future

), it would change the actual results. Not as C-D-G#, but using the midi information such as "sustain C for 100ms, rest for 10ms, sustain D for 25ms, sustain G# for 25ms" to calculate how fast the transition needs to be, and penalize worse fingers in that case ( 4&5 trills, anyone?). Dynamics can also be used to determine the strength of the fingers in question.
But compared to others, they have miniscule effects. I think this model with additions and improvements would capture most of the essence of the actual process; Later than that, instead of hand trajectory /wrist rotation calculations, improving upon the neurological basis (in the first few posts) is much much much more important: you don't choose another fingering because your ring fingers moves 0.4th of a milimeter less; you choose another fingering because you can already coordinate that fingering fluidly.

A comment: When you play a song, very often some mesuares are played several times in differents place of the song, so this measures should be played with the same fingerings. How is going to do that this software?

normally, in a curated piece the repeated measures would start and end with rests; if rests are placed then the fingering would be the same. However, that case may not hold for automatic midi parsing. Besides, the same melody may be played but slightly shifted/from a different key, they would also mostly need the same fingering. Normally, a motif extraction method should be employed to find same/similar repeating blocks of the piece, which would mean more work. Currently, I'm in favor of letting the algorithm decide separately; if the melody is long enough it will find the same fingering for all of the copies in majority of the cases. If not, that's where human interaction would be useful; you just need to limit the first few notes, the others will be found if the starting notes are the same.

TonE · Post by **TonE** » 07-26-09 5:49 am

A comment: When you play a song, very often some mesuares are played several times in differents place of the song, so this measures should be played with the same fingerings. How is going to do that this software?

Imagine following example, take a 1bar melody in 4/4 with 8 * 1/8th notes in it, and repeat this one bar, let us say 10 times. I would assume in the middle sections/repetitions the algorithm should choose anyway the same fingerings. The only question would be what the algorithm will do in the beginning/first bar and the end/10th bar. Meaning as long as the preceding and following bars or patterns are the same the algorithm should also do the same. (I do not know what a professional pianist would say here?)

But if the preceding and following patterns are not the same should the algorithm still choose always the same fingerings, if yes, why? Do pianists always choose the same fingerings in such cases?

Frost wrote:Besides, the same melody may be played but slightly shifted/from a different key, they would also mostly need the same fingering. Normally, a motif extraction method should be employed to find same/similar repeating blocks of the piece, which would mean more work.

I just recently heard about the great Implication-Realization model of Narmour who wrote two detailed books about his "theory of melody". The first one is this, The Analysis and Cognition of Basic Melodic Structures: The Implication-Realization Model. By Eugene Narmour. Chicago: University of Chicago Press, 1990. The second book is, Narmour, E. (1992) The Analysis and Cognition of Melodic Complexity: The Implication-Realization Model. Chicago: University of Chicago Press.

Here is the website of Maarten Grachten, who is a researcher also in that field, and it seems he is very nice, too, meaning he does not ignore your emails. They also wrote already a parser for some parts of the Implication-Realization model. The parsers name is IRParser.exe and it requires as input a textual representation of the midi/phrase/melody in a specific format. Then it outputs the detected
1. IR-structure names,
2. IR-structure sizes and
3. IR-structure overlaps

In short we get kind of more general representation of the melody which we can use e.g. for melodic similarity analysis or melody segmentation.

As a side comment:
As piano fingering is related to piano performance also some ideas from the magic paper "Machine Discoveries: A Few Simple, Robust Local Expression Principles" by Gerhard Widmer might be combined with the ideas we/you

use so far, e.g. to distinguish between "more important notes" and "less important notes" within the composition. The fingering algorithm could e.g. put more importance/weight to those "more important notes" first and maybe use this information to exclude some possibilities from its output list.

Rickeeey · Post by **Rickeeey** » 07-26-09 6:07 am

It starts to sound too complicated. I'm not really into this and haven't even tried it out. Anyways, good luck with it!

TonE · Post by **TonE** » 07-26-09 6:22 am

Another suggestion I want to mention here: Imo we should not treat one hand, e.g. the right hand as a single object when developing algorithms for the fingering. Instead I would treat the right hand as two objects

1. thumb (finger 1)
2. rest (fingers 2,3,4,5)

Why, if you watch a pianists hand while playing piano, the thumb can often also jump quite a lot and these jumps have not much in common what the other fingers are doing on other locations of the piano keyboard. They operate in such case in two separate "piano keyboard spaces" only connected by fast jumps. But maybe Parncutt already considers these jumps sufficiently in his model, I did not read his paper fully yet.

Then we would match mainly two different types of jumps for each hand to the available notes in the piano composition:

1. thumb jumps (this is simple, only a single pitch can be used to detect its position)
2. rest jumps (here we have to consider always local min-max pitch ranges and put the finger 2 normally on min and the finger 4 or 5 on max). Here a very important question would be always: Should finger 4 or 5 be placed on max?

For the beginning I can define a for me yet unsolved problem here:

PROBLEM A:
How sufficiently is it possible to detect thumb positions for a single hand, e.g. right hand, for a given piano composition, no matter if those are just simple non-legato/non-overlapping monophonic melodies or allow also overlappings as intervals, chords, legato or simply just any pitch sets with more than one note (those are called note clusters I think).

A simplified version of problem A would be the same just for monophonic melodies, I am not sure if this simplifies the problem or makes it more difficult actually, at least the melodies are simpler.

PROBLEM B:
How sufficiently is it possible to detect thumb positions for a single hand, e.g. right hand, for a given non-legato/non-overlapping monophonic melodies.

TonE · Post by **TonE** » 07-26-09 8:04 am

Frost wrote:
What is C1 for a midi pitch number in the range of 0..127 or is this unimportant?
it's unimportant. the notes are for just for finding the distances between the keys; notes do not matter at all. (c-d-e is the same as f-g-a due to the placement of black keys)

I want to clarify one more thing. Usually, c-d-e is not the same as f-g-a, why, after e there is no other black key, but after a there is one more black key. But if you would argue c-d-e-f is the same as g-a-b-c then I would agree, this is how octaves are usually split into two tetrachords.

According to the useful book, HARMONIELEHRE (harmony theory/lessons) by Werner Pöhlert, on page 700 it distinguishes among tetrachords following 7 cases of "tetrachord types" based on their black-white-key-combinations:

Type 1 = White tetrachords:
c-d-e-f
g-a-b-c

Type 2 = Tetrachords with a single black key (3. key):
d-e-f#-g
a-b-c#-d

Type 3 = Tetrachords with two black keys (2. and 3. keys):
e-f#-g#-a
b-c#-d#-e

Type 4 = Tetrachord with three black keys (1. 2. and 3. keys):
f#-g#-a#-b
gb-ab-bb-cb

Type 5 = Tetrachords with three black keys ( 1. 2. and 4. keys):
db-eb-f-gb
ab-bb-c-db

Type 6 = Tetrachords with two black keys (1. and 4. keys):
eb-f-g-ab
bb-c-d-eb

Type 7 = Tetrachord with a single black key (4. key):
f-g-a-bb
c-d-e-f (we write this here again which is the first line above, with white tetrachors)

Now we made one round in the circle of fifths counter the quint falling direction, meaning following sequence in the circle of fifths: C-G-D-A-E-B-F#-Gb-Db-Ab-Eb-Bb-F-C
The red ones are enharmonically equal.

Actually it would be interesting also to use such tetrachords for optimum finger placemets for the fingers 2,3,4,5 which I named above as "rest".
So we would find strech values for each of the 7 tetrachord types when played with the fingers 2,3,4,5.

After that we can additionally find stretch values for the same 7 tetrachord types but this time played starting with the thumb, meaning using the fingers 1,2,3,4.

The fingering algorithm could try to detect such similar "tetrachord sections" in the composition and decide whether to play with the thumb (having other strech values), or without the thumb. Then also how these tetrachord sections are shifted within the composition. I think I should stop writing here.

TonE · Post by **TonE** » 07-27-09 2:01 pm

I tested AFP with the default parameter settings with Hanon 1 and here is the result:

Frost · Post by **Frost** » 07-27-09 2:46 pm

the notes look nothing like hanon 1?
..28 32 33 35 25? 35 33 32 30
..33 35 25 27 25 35 33 32

TonE · Post by **TonE** » 07-27-09 5:05 pm

I used as notes input:

Code: Select all

C3 E3 F3 G3 A3 G3 F3 E3 D3 F3 G3 A3 B3 A3 G3 F3 E3 G3 A3 B3 C4 B3 A3 G3 F3 A3 B3 C4 D4 C4 B3 A3 G3 B3 C4 D4 E4 D4 C4 B3 A3 C4 D4 E4 F4 E4 D4 C4 B3 D4 E4 F4 G4 F4 E4 D4 C4 E4 F4 G4 A4 G4 F4 E4 D4 F4 G4 A4 B4 A4 G4 F4 E4 G4 A4 B4 C5 B4 A4 G4 F4 A4 B4 C5 D5 C5 B4 A4 G4 B4 C5 D5 E5 D5 C5 B4 A4 C5 D5 E5 F5 E5 D5 C5 B4 D5 E5 F5 G5 F5 E5 D5 G5 E5 D5 C5 B4 C5 D5 E5 F5 D5 C5 B4 A4 B4 C5 D5 E5 C5 B4 A4 G4 A4 B4 C5 D5 B4 A4 G4 F4 G4 A4 B4 C5 A4 G4 F4 E4 F4 G4 A4 B4 G4 F4 E4 D4 E4 F4 G4 A4 F4 E4 D4 C4 D4 E4 F4 G4 E4 D4 C4 B3 C4 D4 E4 F4 D4 C4 B3 A3 B3 C4 D4 E4 C4 B3 A3 G3 A3 B3 C4 D4 B3 A3 G3 F3 G3 A3 B3 C4 A3 G3 F3 E3 F3 G3 A3 B3 G3 F3 E3 D3 E3 F3 G3 A3 F3 E3 D3 C3 D3 E3 F3

and as fingering reference input:

Code: Select all

1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4

vicentefer31 · Post by **vicentefer31** » 07-27-09 5:17 pm

Only a few weeks ago I thought it was imposible to find an automatic way to do fingerings. But, a weeks ago I didn't know to Frost.
Now, when I play a song, I wonder "why I'm using this fingerings?". And I can notice that I use the same fingerings that I use in the scales and in the Hanon Exercises, and when I find a measure where I can't find an easy "fingerings" I have to think until I find it.
So, maybe this software should have at least two pass:
1:First pass: Find patterns (scales, chords, hanon)
2:Second pass: We have to use algorithms where we can't find patterns.

Frost · Post by **Frost** » 07-28-09 2:00 am

TonE wrote:I used as notes input:

Code: Select all

C3 E3 F3 G3 A3 G3 F3 E3 D3 F3 G3 A3 B3 A3 G3 F3 E3 G3 A3 B3 C4 B3 A3 G3 F3 A3 B3 C4 D4 C4 B3 A3 G3 B3 C4 D4 E4 D4 C4 B3 A3 C4 D4 E4 F4 E4 D4 C4 B3 D4 E4 F4 G4 F4 E4 D4 C4 E4 F4 G4 A4 G4 F4 E4 D4 F4 G4 A4 B4 A4 G4 F4 E4 G4 A4 B4 C5 B4 A4 G4 F4 A4 B4 C5 D5 C5 B4 A4 G4 B4 C5 D5 E5 D5 C5 B4 A4 C5 D5 E5 F5 E5 D5 C5 B4 D5 E5 F5 G5 F5 E5 D5 G5 E5 D5 C5 B4 C5 D5 E5 F5 D5 C5 B4 A4 B4 C5 D5 E5 C5 B4 A4 G4 A4 B4 C5 D5 B4 A4 G4 F4 G4 A4 B4 C5 A4 G4 F4 E4 F4 G4 A4 B4 G4 F4 E4 D4 E4 F4 G4 A4 F4 E4 D4 C4 D4 E4 F4 G4 E4 D4 C4 B3 C4 D4 E4 F4 D4 C4 B3 A3 B3 C4 D4 E4 C4 B3 A3 G3 A3 B3 C4 D4 B3 A3 G3 F3 G3 A3 B3 C4 A3 G3 F3 E3 F3 G3 A3 B3 G3 F3 E3 D3 E3 F3 G3 A3 F3 E3 D3 C3 D3 E3 F3

C3 E3 F3 G3 A3 G3 F3 E3 D3 F3 G3 A3 B3 A3 G3 ....
ah. it fails, because, in the current version, A3 is LEFT of the C3; the alphabet starts at A. It should be A4. So the input parser is wrong (well, not wrong, I designed it that way, but still

)

in the fixed version (that takes the input correctly, the fingering alghorithm is not changed)

: afp-hanon1.jpg (128.08 KiB) Viewed 30736 times

The difference?
Optimal:
1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4
Predicted:
1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 1 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3 2 1 2 3 4

I was going to wait to release the fixed/midi loading version until the other features were done, maybe I should release it as it is now.

Post by **Nicholas** » 07-28-09 2:26 am

Frost wrote:The difference?

Color me impressed. I expected it was going to take a while before we started getting halfway usable results out of this.

A single one-finger difference in 228 notes is something like 99.6% accuracy, right? That's incredible. Congratulations.

Frost · Post by **Frost** » 07-28-09 2:28 am

So, maybe this software should have at least two pass:
1:First pass: Find patterns (scales, chords, hanon)
2:Second pass: We have to use algorithms where we can't find patterns.

I'm thinking about that and have conflicting ideas.

I'll put a limiter that will limit the chords to the user given fingers in every situation (or in every situation that the predicted "optimal" fingering is not that better from the users fingering), to make chords consistent. So, if the user explicitly stated, "Ok, if the notes C E G are played, then use the fingers...", then their preference would be used.
The reason is, chords are mostly played with the same fingers, but the algorithm may find *better* fingerings (well, playing C chord with 1-2-3 is easier

). But consistent fingerings beat better fingerings in piano playing.

However, I currently don't think that explicitly stating other patterns would be better. I mean the software is designed to find the *best* fingering available; if we can quantitatively define what is best; it WILL find it, it's mathematically proven. It's just a matter of defining, what makes one fingering best? How do you differentiate between one fingering and the other, and say this ones better?

Hanon fingerings and scales are designed that way, they minimize hand movement etc. and are the most comfortable. As you see in the post above, it finds the hanons correctly, because, well, it's the way it should be.
For example, in my hanon sheets, in some exercise there was a printing error in only 1 finger; but due to that, the fingers were totally off, it was uncomfortable and not fluid. I practiced at it, thinking, "well, I guess this is to prepare for the different pieces that call for such weird fingerins". When I found out that the fingering was wrong, it should be 5 instead of 3, *then* it made sense. If you made me play it with the wrong fingering, I would have thought this is how it should be and try to suppress my *optimal* fingering, (which was actually the correct one according to Hanon), and get used to that fingering. In the future, I may had even became a "correcter", that says, no no no, use these fingerings instead, they would help you better.

I want the design the algorithm such that, it will find the optimal one, what Hanon/Czerny/others would have suggested. IF it's different than what the pianists are thinking, I should be able to say "NO, the fingering algorithm finds is better; that pianist is wrong", unless the pianist can explain explicitly why theirs is better.
So, I don't want to explicitly state the hanon patterns, scales etc., because that's what it should find anyway. If it can't find them, then there is a problem somewhere, and the problem should be fixed in any case.

vicentefer31 · Post by **vicentefer31** » 07-28-09 4:15 am

Hi Frost,that's 99.6% accuracy in Hanon nº1 is amazing!!!

TonE · Post by **TonE** » 07-28-09 4:58 am

That looks great Frost, you are a magician.

If AFP performs already that great we can start thinking about including the full sets of

1. Hanon
2. Czerny

with their full correct fingerings in Synthesia. Later even more other such interesting beginner training sets might be added. Imo also understanding fingerings yourself is more important than believing any other pianist blindly, even if your feeling tells you another fingering is more comfortable to you, we should trust in such cases ourselves more.