|
In this document, we will define which kind of errors
will be handled by the program, and discuss about the program's tolerance.
I - Error types
I.1 - Note errors
I.1.1 - Wrong Notes
The note played in the performance is not the expected one : [A, C#, F]
instead of [A, C#, E]. The error criterion is the pitch of the note
I.1.2 - Skip Notes
A note is missed by the performer : [A, C#, E] instead of [A, C#, F, E].
Error criteria are the pitch and the time of the note
I.1.3 - Extra Notes
A note is added by the performer : [A, C#, G, F, E] instead of [A, C#,
F, E]. Error criteria are the pitch and the time of the note
I.2 - Tempo and rhythm errors
I.2.1 - General tempo errors
A part of the piece is played on a different tempo as the one expected.
This feature should be chosen by user : the performer may want to train
on a part while playing it slowly
I.2.2 - Duration errors
Played note duration is note the one expected : [100, 50, 100] instead
of [100, 100, 100]. Error criterion is relative release time ([release
time] - [start time])
I.2.3 - Start time errors
A note is played earlier or later than expected [0ms, 100ms, 200ms] instead
of [0ms, 200ms, 400ms]. NOTE : we must not detect a start time error just
after a duration error, since they are often related : this would lead
us to detect 2 errors instead of only one.
I.2.4 - Lack of regularity
Regular repeated notes are played with different times : [0, 50, 90, 150,
210, 250] instead of [0, 50, 100, 150, 200, 250]. Such errors are a kind
of start time errors, but their musical signification is important enough
to class them into a particular category.
I.3 - Dynamics and phrasing errors
I.3.1 - General dynamics errors
A part of the piece is played louder or softer than expected : mp instead
of mf. Error criterion is note velocity.
I.3.2 - Accentuation errors
Same thing as dynamics errors, but mainly for single notes. For example,
a "should-be-accentuated note" is played with the same dynamic
as the others
I.3.3 - Staccato / legato errors
A staccato (resp. Legato) phrase is played legato (resp. Staccato). Could
be classified as duration errors, but have enough musical signification
to be one distinct category.
I.4 - "A posteriori" classification
Error classification could not (and should not) be made in real-time.
Let's take the note errors as example :
If a "wrong note" is detected, before determining which kind
of note error we have, we must wait to see what happens next. If next
played note is the one expected after the one detected as wrong, then
we have great probability to have a wrong note error. If the note detected
as wrong is the one expected just after, we can consider it as a skip
note. And if the note played after the wrong one is the one which was
expected, then it can be handled as an extra note.
This implies we must have a quite large working window
to see clearly what happens arround the note which is actually played.
II - Tolerence - Threshold values
II.1 - Note pitch (note errors)
Since we decided to work with a MIDI input, we don't have many difficulties
to define what is a right note and what is a wrong one : The pitch of
the played note is not exactely the same as the expected one, then we
have a wrong note.
II.2 - Note and Rest duration (rhythm errors)
Things cannot be here defined in a "binary way": We must introduce
a threshold delta and consider that the played duration d
is right if we have :
(expected duration - delta) < d < (expected
duration + delta)
Threshold value should depend on note's own duration, and not exceed
50% of this duration. The precise definition of this value will depend
on what the player (or the teacher) wants : it can not be the same value
for a beginner and for an experienced musician, and from a musical piece
to another. Let's take an example :
A piece of J.S. Bach, with a lot of repeated and regular notes, has to
be played with a strong exactitude. The d value should not be too high.
On the other hand, in a piece of Chopin where player's own "feeling"
affects the general rhythm, we should not consider that would be an interpretation
as an error. The threshold value should be here higher.
A good compromise would be to give the possibility to the user to define
the value corresponding to the musical piece. This threshold value would
become a parameter of the score, and directly correspond to the musical
style of the piece.
II.3 - Dynamics - Note velocity
II.3.1 - General dynamics errors
This becomes here much more subjective. We have two ways to detect these
errors : First, we can have the same idea as for note duration : compare
the played note's velocity to the expected one, and validate it with a
threshold :
(expected velocity - delta) < v < (expected
velocity + delta)
The second way would be to define a "velocity scale" which
would give, for each velocity value, the corresponding dynamic :
Between 0 and 10 : ppp
Between 10 and 20 : pp
Between 20 and 40 : p
Between 40 and 60 : mp
Between 60 and 80 : mf
Between 80 and 100 : f
Between 100 and 120 : ff
Between 120 and 127 : fff
The great advantage of this solution is an independant definition of
dynamics. If rhythm is a fuzzy concept and can be different from a piece
to another, a mezzo-forte will always be a mezzo-forte, and this notion
is totally independant of the musical style of the piece.
II.3.2 - Accentuation errors
We must here consider note velocity in comparison with both previous
and next note. If the note should be accentuated, then we can say we have
no error if :
( v > Velo(previous note) + delta ) AND
( v > Velo(next note) + delta )
For accentuation problems, we just need relative velocity : we don't
care about absolute values, since the wanted effect of an accentuated
note is to make contrast.
|