Respect the key when drawing notes.

Don't print accidentals when they are already in the key, and add
naturals when needed because of they key.

Add a keybinding for Enter to clear all notes

This shouldn't actually be necessary, but in case there are ever any
stuck notes, this can help to clear them.

Rework computer keyboard input to be mapped piano keyboard

Instead of using computer keyboard letter names for piano note names,
(which allowed only entering natural notes), we now map the piano
keyboard onto the computer keyboard. The naturals are on the home row,
(middle C is on 'A' and the next higher C is on 'K'), and the sharps
map onto the top row in the obvious position, (C# on 'W, D# on 'E',
etc.).

Add support for drawing a key signature

This works correctly for treble and bass clefs and up to 7 sharps or 7
flats.

The key does not yet influence the way notes are drawn, (which
accidentals are displayed), nor yet how chord names are determined.

Fix bugs in mismatched spelling of chord name and notes

When the notes of a chord were re-spelled to match the degrees of the
matching signature, the root note was not being updated, so the
chord-name symbol still reflected the name of the un-respelled root
note. This was a bug introduced in the recent shakeup to do analysis
more entirely in the scherzo layer without using score_note_t.

Fixing this required a fair amount of refactoring. Hopefully the
result is cleaner and more maintainable.

Fix to resize staff when ledger lines are no longer needed

This restores the original behavior which was inadvertently lost in
some recet code refactoring.

Make score_note_t entirely private to score.c

And drop the remaining functions that are no longer being used.

(These were easy to find as the only remaining functions in score.h
referencing score_note_t.)

Makefile: Add -Wmissing-declarations compiler option

Some recent code changes should obsolesce some functions, so it will
be nice to have compiler help in finding them.

Change the various score add_note functions to not return a score_note_t.

With the callers no longer doing anything with this return value, we
can now drop it entirely.

Use a pitch_t rather than a score_note_t for challenge

This continues the recent trend of removing the use of this
score-specific data structure from the scherzo layer above score.

Fix scherzo to use pitch_t rather than score_note_t for computation

The score_note_t type is constructed as a side effect of performing
drawing. This is a poor fit for scherzo's computation and reasoning
since it often wants to perform analysis on notes that it has never
drawn.

Meanwhile, the new pitch_t is a simple integer, making it very easy
for scherzo to use pitch_t in all of its calculations.

The goal is for no functional changes with this commit, but we know
that some bugs have likely been changed or moved around.

Encode octave within pitch_t value

This simplifies the code quite a bit. Instead of passing around pairs
of (pitch, octave) all over the place a simple pitch_t value suffices.

Drop the enumerated pitch values.

It's really just as easy to use macros such as PITCH_LITERAL,
PITCH_NAME, or PITCH_ACCIDENTAL in some combination instead of using
an enumerated pitch_t value.

In place of the enum, we now have pitch_t as a uint32_t type.

The real purpose for doing this is to prepare for pitch_t to be able
to hold the octave as well which should be remarkably convenient.

Port all code from score_pitch* to pitch*

Tracking the new interface in pitch.h, (and deleting the compatibility
defines from score.h).

Move large portions of score.h to new pitch.h file.

This is in preparation for doing more score-independent reasoning
about pitches.

At this point, compatibility defines are left in place so that none of
the code has to change yet.

Abbreviate "unknown chord" to a simple question mark

This gets the idea across, and is less distracting when it appears
transiently while pressing or releasing the notes of a chord.

Use matched chord signature to guide spelling of note on staff.

We now use the chord's signature to choose the correct spelling of
each enharmonic note. For example, an A mjor triad has a C-sharp in
it, not a D-flat. We can determine this since a major triad should
have a note of the 3 scale degree (as recorded in the chord
signature).

Still to be done is to draw note heads without collision, draw
accidentals without collision, and to improve the heuristic for
deciding between ambiguous chord signatures.

Fix signature for "sus" chord

This signature had an ''augmented'' 3rd in it rather than the perfect
4th that was intended. The perfect 4th is the thing that will allow
the chord to be spelled correctly.

Put all chord signatures into a single array

This simplifies the code quite a bit. Instead of a big switch
statement based on number of notes in the chord, with each case a
nearly-identical for loop, we can have one single for loop for all
signatures.

More importantly, this means that after the for loop has matched a
signature, we can have a single variable pointing to the matching
signature. That will be important for using the signature to guide in
spelling the chord correctly, which we hope to do soon.

Don't print the inversion names

These were just too long for a very little bit of information,
(perhaps in the future I'll decide to bring back the inversion
information but with a style such as C/G for a C major triad in 2nd
inversion).

Use abbreviated names for intervals

Don't print root pitch for octaves and intervals

The bare pitch name looked too much like a major triad.

Add voicings of m6/9 and m6/♭9 with no 5th.

This clears up a FIXME comment suggesting that we were missing some
chords with perfect 5ths. The comment was somewhat incorrect. One
chord was present all along. One should have been present, but was
incorrect (until the last commit). The third was legitimately missing
(until the last commit).

Now that we have all of these in place with perfect 5ths, we can also
add the versions voiced with no 5th at all and delete the comment.

Fix bug preventing recognition of m6/9 and add m6/♭9

The line that was supposed to detect m6/9 had an incorrect signature
identical to the signature of 6/9 (causing m6/9 to never be
recognized).

While we're at it, add m6/♭9 as well.

Add voicings for 7th chords without 3rd and without 5th

This does introduce a few more ambiguities. I need to write a mode
soon to search out and print all the ambiguous chords.

Comment a couple of ambiguous chords

I noticed these while going through Bach's Prelude #1, comparing what
scherzo gave with what Andrea Pauly gave for each chord.

The right thing to do is probably to make scherzo display all chord
names (and spellings) when more than one chord naming can be matched
against a set of notes.

Drop 'm' before half-diminished or diminished symbol

The chord no longer has minor quality once it's half-diminished or
diminished.  Putting the 'm' in there was just confusing.

Add +M7sus and +7sus chords

I'm not sure why I didn't have these here before, when I had +M9sus
and +9sus.

Reduce overuse of superscripting in chord names.

In particular, the presence of "sus" now no longer triggers
superscripting in the rest of the chord name, (since I've moved "sus"
to the end of the chord name instead).

Add some 7th chords with an added, altered 9th interval

These are named 7#9, 7b9, 7b5#9, and 7b5b9.

Recognize the 6/9 chord and the m6/9 chord

Starting to add chords mentioned in the first couple of pages of Jazz
Chord Progression by Bill Boyd.

Add 11th chords

Working from:

http://en.wikipedia.org/wiki/Chord_notation#11ths

I still have some confusion about half-diminished and diminished
chords larger than 7th chords. The 9th and 11th versions of these as
currently programmed seem inconsistent. So I need to double-check
against some additional sources rather than just relying on wikipedia.

Add some flat-5 variants of 9th chords

I also noticed these when reading the following about 11th chords:

Omission of the 5th in a sharpened 11th chord reduces its
sound to a flat-five chord.

[http://en.wikipedia.org/wiki/Chord_notation#11ths]

Add sus (sus4) versions of the ninth chords.

As I was reading about 11th chords here:

http://en.wikipedia.org/wiki/Chord_notation#11ths

I noticed that an 11th chord voiced without a 3rd becomes a 9sus4
chord. So let's recognize those.

Specify sus4 chords with a Perfect 4th rather than a raised 3rd.

This is much more clear, (and will help when I actually write the code
to spell these correctly on the staff itself).

Add ninth chords.

I worked from the list in this table:

http://en.wikipedia.org/wiki/Chord_notation#9ths

and included some generalizations, (including the voicings without the
5th as mentioned on the page above).

I did not yet add any "sus" variations. I'm not sure how useful those
are.

Add recognition of sus2 and sus (sus4) chords.

I'm not sure that all of this is exactly correct, but I'm trying to
implement the rules described here:

http://en.wikipedia.org/wiki/Chord_notation#Suspended_chords

Add recognition of 6, m6, and 7-flat-5 chords.

One trick here is the ambiguity that, for example, C6 looks the same
as Am7 in first inversion and Cm7 looks the same as D#6 in 3rd
inversion. We rework the recognition code a bit so that chords with a
smaller inversion number will be preferred over chords with a larger
inversion number. That way, with the above examples, scherzo will
report C6 and Cm7 rather than "Am7 1st inversion" and "D#6 3rd
inversion".

Drop the "M" from the name for a major triad.

It's simpler (and well-understood) that a "C" chord is a "C major
triad". We don't need to call it "CM".

Take advantage of pango markup to draw superscripted chord names.

Now instead of things like "C Major triad" we have shorter names like
"CM". Instead of "Augmented" we have a superscripted degree symbol,
etc.

Switch to using pango, not cairo_show_text for chord names

The motivation here is to enable sub-scripting of chord symbols.

Detect the root pitch of chord and display it

One ugly thing here is that any accidental in the chord name is in a
different font than the accidental on the stave.

Add a few initializations to quiet compiler warnings.

My manual analysis says that none of these are strictly necessary,
(the various conditionals currently ensure that none of the variables
are ever used uninitialized). But "gcc -O2" likes to complain, so
these initializations keep it quiet.

Default to compiling with debugging symbols.

Which is obviously much more convenient for debugging.

The user can still override this with something like:

make CFLAGS=-O2

Add support for recognizing inverted chords.

This isn't using any fancy figured-bass-derived names for these
yet. For now, it's just spelling things out as "1st inversion", "2nd
inversion", etc.

Switch to a degree-specific scheme for specifying chord signatures

The old scheme specified each chord signature by the number of half
steps between the root note and each note of the chord. This made it
impossible to distinguish between alternate names of enharmonic chords
(such as an augmented 4th and a diminished 5th which both have 6 half
steps).

The new specification indicates which degree should appear in the
chord, and which modification each degree has, (from -2 to +2 half
steps).

So, under the old scheme an augmented 5th/diminished 4th would appear as:

{0, 6} /* Half steps from root to each note */

And in the new scheme these can be identified separately as:

{{1, 0}, {4, +1}} /* Augmented 4th */
{{1, 0}, {5, -1}} /* Diminished 5th */

We don't yet have much of a user-visibile change with this commit,
(other than that the above interval will now only be identified as a
"Diminished 5th" rathern than the "Augmented 4th/Diminished 5th" we
had before).

But this gives us the necessary information we will need in order to
correctly spell chords on a staff after the chord has been identified.

Allow computer-keyboard input of accidentals, and draw accidentals.

All accidentals are drawn assuming the key of C major, for now. That is,
natural symbols will not be drawn, but all other accidental symbols will
be drawn.

No care is taken to avoid accidentals colliding with each other when drawn.

Add a new SCORE_PITCH macro and rename SCORE_PITCH_VALUE to SCORE_PITCH_LITERAL

The original SCORE_PITCH_VALUE macro was of limited use. It could only
be used with literal values such as "G" and "FLAT" and could not be
used to construct a score_pitch_t value from two variables. This was
particularly useless since a user could just use a literal value of
SCORE_PITCH_Gf instead of SCORE_PITCH_VALUE(G, FLAT).

So we rename SCORE_PITCH_VALUE to SCORE_PITCH_LITERAL to make its
limitations more clear in its name. (The one important use remaining
for the macro is in the initial construction of the score_pitch_t
values for the enum declaration).

And here we add the SCORE_PITCH macro which *can* be used to construct
a score_pitch_t value from two variables, (one holding the pitch name,
and one holding the accidental).

Don't bother looking at signatures that we know can't match

Only look at signatures which have a length the same as the number of
notes in the current chord being analyzed.

Re-order the signatures array for the seventh chords

It seems easier for me to think about these ordered from widest triad
to narrowest, and the from widest seventh to narrowest.

Simplify chord-signature matching by dropping duplicates first

Previously, all the duplicate notes were still present in the chord
while trying to determine if the duplicate matched. Now, we cull out
the duplicates before looking for a match, which makes the matching
code much simpler.

Avoid duplicating notes within note_group_t and score_staff_t

Previously, it was possible to have notes "stick" on the staff and not
clear off after releasing the note or pedal in some circumstances. We
fix a number of these bugs by checking to see if a note is already
present in a list before adding a duplicate copy of it.

Fix bugs in analysis for out-of-order chords

When the various notes of a chord were in different octaves, scherzo
was sometimes getting confused and was unable to match the chord to
its known signatures. We fix this by adding a secondary sort, (first
sort by absolute pitch to find bass note so to compute relative pitch,
and then second sort by relative pitch).

Add analysis support for octaves

It just looked stupid for scherzo to call a perfect octave, "unknown
or not a chord".

Fix chord analysis for intervals larger than an octave

By simply repeatedly subtracting 12 from any larger-than-octave intervals.

Add support for pedal

As scherzo listens to the pedal, it will analyze the chord harmony based on
notes that continue to sustain due to the pedal.

I'm not 100% comfortable with the empirically-derived value of 64 for
the sustain pedal. I'd feel a bit better if I had found a symbolic
constant for this in the ALSA header files. As things stand now, I'm
not sure if the sustain pedal on another keyboard will return the same
value.

Allow keys 0-8 to specify desired octave.

This allows specifying notes across a wider range than a single octave
with the computer keyboard.

Don't put up "unknown chord" for a single note

It's obviously just a single note, and not anything else, so don't say
anything.

Add recognition of intervals.

This is quite easy with the same machinery as the chord recognition.

Add recognition of 7th chords

There's still no recognition of chords in anything but root position,
(and the accidentals are still not yet drawn on the staff).

Add preliminary chord analysis

With this commit, challenges are disabled (for the moment), and
scherzo will analyze the notes pressed as a chord.

Currently, only the four basic types of triads (augemented, major,
minor, and dminished) are recognized, and these only in root position.

Fix the broken SCORE_PITCH_NAME macro to work correctly

For no good reason, the score_pitch_name_t enum had previously been
defined with pre-shifted values. That could have worked, but the
SCORE_PITCH_NAME macro was shiftin the masked value down as if the
enum values were not pre-shifted. So SCORE_PITCH_NAME was yielding
unexpected values, (that did not correspond to score_pitch_name_t
enum values).

We fix this by making the enum sane, (with unshifted values), leaving
the shifting in place in SCORE_PIATCH_NAME and tracking the new style
of the enum by adding shifting to the SCORE_PITCH_VALUE macro.

That is, the macro that is changed by this commit reamins working, and
the macro that is left unchaged by this commit is now fixed.

Rename mnemon data file from "scherzo" to "scherzo-notes"

This is in preparation for having "scherzo-chords" and others.

Update sub-module path for menmon with a relative path.

This is an attempt to give people cloning scherzo a chance for it to
actually work.

Add ability to perform input with computer (not midi) keyboard.

This is useful for testing when away from a keyboard, and also useful
in its own right for ensuring that the user knows the names of the
notes (not just their position on the piano keyboard).

When using a computer keyboard for input only the note name itself is
needed---the correct octave is chosen automatically.

Add some color coding of input notes.

Red for an incorrect note, and green for correct. (The challenge notes
remain black.)

Shrink staves once ledger lines are no longer needed.

This is not extremely aggressive. It will only shrink once a staff has
no notes left.

Add correct sizing/spacing of staves and braces for ledger lines.

At this point, we're ready to run quizzes for any white key on the
piano.

Draw ledger lines.

It's almost getting to be a usable program now.

Don't queue up as many widget redraws.

For multiple MIDI messages in a single buffer, only queue a single redraw.

GTK+ should be coalescing these anyway, but we might as well not make
it work any harder than it has too.

Fix another bug with stuck notes.

When multiple MIDI messages were received in a single buffer, the code
was neglecting to advance the string pointer it was using to
parse. This was causing it to parse the first message several times
and ignore all following messages.

Fix this silly bug.

Fix bug with stuck notes when challenge would switch staves.

In this case we were failing to remove a note beacuse we were looking
at the new staff (where the new challenge is) rather than the old staff
where the note was originally created.

Fix this by having each note remember the staff it's created on. This
also impacts the API a bit (no longer need a staff argument to
remove_note, so drop the "_staff" portion of the name from both
add_note and remove_note).

Integrate some simple mnemon quizzing into scherzo.

This will be a lot more interesting once we start drawing ledger lines
and accidentals. But it's already useful for white-key practice for
the notes directly on the staff. Could definitely use better feedback
such as different colors (or even just different horizontal spacing
for challenge vs. response notes).

Add mnemon code as a git submodule

The scherzo code will be taking advantage of the mnemon code as if
it were a library of sorts.

Open MIDI device and display notes being played in real time.

Every time a key on the MIDI input device is pressed, a whole note appears
on the appropriate staff. When the key is released, the note disappears.

No ledger lines are drawn yet, and there appears to be a bug where notes
get stuck on (refusing to disappear after a key is released) triggered
most easily by pressing *many* keys simultaneously several times.

Ignore the .deps directory.

This contains generated files only, nothing we want under revision control.

Start drawing some very rudimentary notes.

I'm picking the correct (but hard-coded by glyph index) noteheads
out of the Gonville font. But I'm not drawing any stems nor flags
yet. Also the spacing between the notes isn't interesting yet, nor
do I have measure lines, nor ledger lines.

Oh, and the notes I added here for testing aren't even musically
interesting either. Anyway, we're still getting started obviously.

Makefile: Fix automatic generation of dependencies.

Without this, updates to the header file were not triggering rebuilds
of the source. Things are much more convenient with this.

Restructure code to manually add staves, braces, and notes.

Previously, the program was hard-coded to draw a grand staff, (two staves
connected by a brace). Now, at the level of the score library, each staff
and any braces are added manually and any set of staves and braces can be
drawn, (the only the two-staves-connected-by-one-brace has been tested).

There's also functionality for ading notes, though no notes are drawn yet.

Increase the default staff height just a bit.

At a height of 48, it's more comfortable to view, (while still having
a line_width of 1.0 for the staff lines).

Make the brace and clef symbols scale with the staff.

All looks much better now, (even if the size calculations are simply
empirically-derived linear fits to what looks good to me).

Add some scaling controls with plus/minus keybindings.

Total cheese in that the symbols (braces and clefs) don't change size yet,
but at least the line widths snap to nice integers.

Add some (particularly cheesy) drawing of a brace and clefs on the grand staff.

This assumes the presence of the Gonville-26 and Gonville-Brace fonts, (by
Simon Tatham). Though it would be simple enough to change the code to use
any Lilypond-compatible font, (if the glyph selection were also update or
just fixed to lookup glyphs by name instead of hard-coding the index).

Draw a second staff (and vertical lines at the beginning and end of staff).

This is almost the grand staff necessary for a piano score, (missing
the brace). The _draw_grand_staff function is a bit too specialized. A
more general approach will involve the ability to add an arbitrary
number of staffs (staves?) to the score, and selectively tie some
together (with or without a brace).

Start drawing something

So far, just a few simple staff lines.

Add a .gitignore file.

Initial commit of scherzo.

Nothing more than a simple GTK+ window so far.