By the time 1 month had gone by, it was clear that the peanuts xmas song would not be transcribed in time.  Lion readable music notation from MIDI is a hard problem.

Reverse engineering the MIDI protocol from hex dumps instead of formulating an AI prompt, revealed the start codes are ored with 0x80.  All the other data is limited to 0x00-0x7f.  The packets are variable length.  Sometimes they're 4 bytes ending in 0.  Sometimes they're 3 bytes.

The 1st step was using the right pedal to go forwards 1 note & the left pedal to go backwards 1 note.  The right pedal needed debouncing in the form of 2 analog levels.  The left pedal seems to have hysteresis of its own.

Then to do cross development on raspberry pi, it became clear it needed to switch between single monitor, dual monitor, & 3 page single monitor mode at runtime.  3 page single monitor remanes a notional mode if lions can ever afford enough space. 

Managed to get some peanuts transcribed by capturing MIDI keypresses.  A lot of behaviors have yet to be fixed, manely more 8va corner cases, undo stack corner cases, accidental corner cases. 

--------------------------------------------------------------------------------------------------------------------------------------

 It quickly became clear that it needed some minimal indication of timing or measures.  The reason we have bars is the same reason serial data has start bits.  The trick is an object which spans all the staves.  The bars could be in a 3rd staff, which leaves a need for the user to manually shift them sideways without a time signature.  We have rests to shift notes sideways.

The top staff could be designated as the bar staff & they would follow only edits in that staff.  The problem is the time values in the bottom staff still need to skip the bar time.  The bars in a 3rd staff could just follow the time values in the top staff.  There's no dragging, dropping, cutting or pasting of objects in the score.  There are only rests for horizontal alignment.

The easiest solution ended up being separate bar objects in all the staves, with the polygons & time shifting based on the top staff.  All the edit operations need a unique, quirky behavior to update the bars & 8vas.  Edits below the 1st staff would shift everything besides the bars while edits in the 1st staff would shift the bars in all the staves.  Deletion & insertion of the bars themselves would shift everything in all the staves.  

Ended up requiring the user to specify when edits shifted the bars.  Adding a note in 1 staff would entail checking the option, adding the note in 1 staff, then unchecking the option & adding a rest in the other staff.  The mane problem is the lack of any timing information preventing auto computation of the bar positions.  It might need a set of general drag & drop tools.

The lack of measure wrapping means it can't draw bars on the sides.  Measure wrapping would create the problems of a measure that's too wide to fit on a single line or a case of no bars being defined.  Finale required the user to call a reformatting command to wrap the measures.

---------------------------------------------------------------------------------------------------------------------------

The other big problem was playback of the source audio file from preset times.  This still needs a full computer.  No phone audio player has quite the same capability.  Minidisc recorders could create preset times, but modern phone players are only designed for consumption.  Then the phone output needs to be mixed with the piano output.  The lion kingdom would be so lucky if its minidisc recorder still worked. Went through 2 & all the spare parts.  The replacement gears suffered from some age related degradation.

1 idea is to have the https://hackaday.io/project/178292-piano-signal-processor

signal processor import sound files.  The user would upload the file to the raspberry pi.  Then the phone app would load a proxy for a waveform display.  The phone app would have transport controls that sent commands to the raspberry pi.  The raspberry pi would mix the sound file with the piano output.

The bigger bang for the buck is going to be a novel phone media player with a waveform viewer, precise seeking, & labels.  It could be extended to have recursive playlists.  The output would go in the line-in on the raspberry pi & the signal processor would have to provide a line in level.

Finally, there is a debouncing problem in the custom trackpad.  The source code has a 10ms debounce value.

Simultaneous use of the reader mode & manipulating of the pdftoreader2 program can show a reference score on 1 monitor while capturing MIDI on the other monitor.