Project Logs

Collapse

• More staves

  lion mclionhead • 12/02/2025 at 06:21 • 0 comments

  Got it to show arbitrary numbers of staves.  The mane trick is aligning the beats in both staves.  Currently, it's hard coded to create 2.  Then came 8va symbols, which were a brute force coding job. 
  

  Exercised it drawing lowest A & highest C.  It's going to need adaptive staff spacing, but it's going to be rarely used.

  All the drawing used X primatives & pixmaps instead of the more modern method of drawing on a bitmap & blitting or using a modern library.
  

  The next step was persistent storage.  Lacking a keyboard or desire to type with a mouse, it just automatically creates a filename.  The user has to ssh in & rename it.  This is what the headless sound recorders have always done & it works well.  https://hackaday.io/project/28716-ultimate-4-channel-audio-recorder

  Maybe it's time to make a web based file manager for all these headless programs, like webphone.
  

  Banging out the persistent storage reminded lions that the music reader program has been on raspberry pi for 5 years & it uses the same GUI library as Cinelerra.   Also, ffmpeg was easy to build on raspberry pi.   Cinelerra could easily compile on a 64 bit raspberry pi but it would need a KVM.

  Just text files with automatically created filenames.

  Next came the insertion point & clipboard operations.  Insertion point operations comprise thousands of things. 
  

  The finale videos all showed a solid, unblinking cursor without XOR.  Some of the big operations were deleting single beats, cursor key navigation, mouse navigation, changing staffs & beats, wrapping around the end & beginning of the score, reducing the length of an 8va when deleting a beat.

  Music notation with line wrapping is such a difficult problem, there's no other way to do it but grinding away at diabolical software constructs or in today's lingo, diabolical prompt constructs.  When in doubt, creating more data structures tends to unblock the process.  It's most often necessary to reread different sections of arrays & search in both directions.
  

  To keep things moving, usage would focus on just inserting & deleting single notes at a time instead of full clipboard operations.  Music construction set avoided the problem by drawing a single infinitely wide line.  To be lion readable, it needs line wrapping & paginating.  Noted MCS had all the 8vas extend to the next bar. The notes were only drawn for X < 255 & the play head was indicated by a carrot.

  Important to note that the resolution imposed by the ancient laptop monitors is comparable to 80's VGA.
  

  For clipboard operations, the finale examples showed blue highlighted regions without XOR.  The mane problem with clipboard operations is selecting regions with variable numbers of staves, multiple lines, & pages.   It's not known if the score is going to advance by pages or lines.  The music reader did fine with no clipboard operations or region selections for its annotations.
  

• Lilypond concept

  lion mclionhead • 11/30/2025 at 01:17 • 0 comments

  It turns out there are many standalone programs which convert MIDI to an input file for lilypond.  

  https://lilypond.org/doc/v2.24/Documentation/usage/invoking-midi2ly

  It's unknown how well they work.  The MIDI converters still have to perform automatic accidental assignment.

  The pipeline would begin with MIDI data hacked to produce shortpaw notation.  Lilypond would be called to output a PNG image.  It would redraw the entire captured score after every MIDI event.  The only missing pieces are extents of all the notes for graphical editing & drawing of an insertion point.

  https://lilypond.org/doc/v2.24/Documentation/usage/configuring-the-system-for-point-and-click

  There is some support for hyperlinking its PDF & SVG output.  That seeds the output files with coordinates of each note, in a roundabout way, but you have to render PDF or SVG output.
  

  https://lilypond.org/doc/v2.24/Documentation/notation-big-page.html#graphic
  

  It does support drawing polygons in arbitrary colors to indicate the insertion point.  Arbitrary notes can be colored to indicate where an edit would be applied.  Navigation could be through arrow keys.
  

  It's unknown if it's fast enough for interactive MIDI capturing an entire score & cursoring through all the notes.  It seems the pipeline would have to render 1 measure at a time & resort to custom software for line wrapping.  That would only be practical if all the notes were the same duration. 
  

  Most of the lilypond example scores are on https://www.mutopiaproject.org/instruments.html They were manely manually transcribed 10 years ago.  There are a lot of version incompatibilities.
  

  It takes 2.5 seconds to render the 4 page rach prelude in C# minor on a 2.4Ghz ryzen.  It takes 1 second to render 1 page examples, 2.6 seconds to render the 6 page revolutionary etude.  That would be pretty slow for incremental MIDI capture.

  Not sure why it's so slow.  It might be rendering every bezier curve in the notation font files.  Someone made a lilypond server 10 years ago.

  https://github.com/lyp-packages/lys

  Similarly noting the slowness.  The claimed speed improvement still wasn't very compelling.
  

  https://lilypond.org/easier-editing.html
  

  The interactive front ends all seem to use their own low fidelity music renderers for graphical editing & use lilypond for a high quality final output.  At this point, what lions have done from scratch could still be useful for the capturing stage but it could never produce a final score.
  

  The only way to convert that into a final score would be to export a lilypond file.  Of course, there would be no way to insert further MIDI data after it's in lilypond format unless lilypond was also used for the capturing.  Still not practical if it's rendering 1 measure at a time.  After applying timing, computing all the measures would be a rough go.  Amendments like that might be rare & minor enough to not require reloading in the MIDI capture program.
  

  Helas, the raspberry pi's in the music display are very slow & would have to be reflashed to compile lilypond.  Lions aren't financially prepared to upgrade.  It would entail a 4k monitor.  For the MIDI capture, it has to do a lot of stuff outside of lilypond, basically most of what it does now with accidentals, staffs, key signatures, & an insertion point.  That wouldn't go way.

• MIDI transcriber kickoff

  lion mclionhead • 11/29/2025 at 08:42 • 0 comments

  The MIDI transcriber would be an extension of the previously written https://hackaday.io/project/179967-lcd-music-display music display, since lions never expect to have a piano & a PC accessible at the same time.
  

  The lion kingdom had a novel shortpaw notation system in mind for over 30 years, whereby all the notes were whole notes on an ordinary staff, timing wasn't indicated anywhere.  It was just enough to play a piece with memorized timing but not as cryptic as an ordinary MIDI graph, not as minimal as a lead sheet.  Timing could be manually set in a 2nd pass.  The trick was getting the music display into a notation capture mode & developing the interface.
  

  Notation capture would most likely be a toggle in the music reader menu.  It would be a totally separate interface. The music reader would perform MIDI capture & playback over USB.  The page turn buttons could advance to the next note or rewind to the previous note in capture mode.  The motivation for revisiting this was the desire for a better arrangement of the Charlie Brown xmas theme.

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

  After a solid week on this, the reality of how hard it is became clear.  When transcribing a MIDI keypress into human readable notation, there's a nasty translation through the current cleff, current key, current octave, current accidental.  It's a lot harder than dragging & dropping notes.  That's why the cheapest music entry programs are just type setters.

  Some diabolical algorithms managed to compute shortpaw notation directly from MIDI pitch codes.  A cleff & key still must be provided.  The trick with development is to create a database of synthetic MIDI codes with a variety of test cases.  Automatic prediction of the accidentals is still a black art.  Finale never chose perfect accidentals either.  It basically adds sharps if the key is flat & adds flats if the key is sharp.  It adds naturals if the closest position on the staff is a natural.

  Being shortpaw notation, the accidentals currently reset for every note.  It still probably needs to indicate canceled accidentals to be readable.
  

  Of course, what we really want is the least number of accidentals.  This requires applying knowledge of all the preceding accidentals in the measure, a diabolical problem indeed.
  

  The general idea is the pitch code is going to be fixed & can only be set through MIDI capture.  The theory is the user would manually override the automatic accidentals by dragging & dropping a new accidental.  The indicated note would move up or down by the necessary amount for the new accidental to result in the same pitch that was captured.

  A few more days led to an algorithm which always draws accidentals if they're different than the key signature.  If they're the same as the key signature, it resets the accidental once.  The next step would be user defined accidentals.

  In this case, MIDI code E + a user defined flat caused it to draw F flat.  Then MIDI code F with no accidental made it draw a natural.  The idea is the MIDI code being fixed & only the notation changing based on the addition of an accidental.  The next step would be supporting a bass cleff, with the option to change the number of staffs at different times.

  The next big challenges were line wrapping, specifying keys, cleffs & suddenly even shortpaw notation was proving a pretty daunting task.

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

  Lacking a keyboard, a lot of dragging & dropping is still going to be required for the multitude of required symbols.  Music construction set used a very slow process of dragging accidentals, dots, ties, rests, bars while the...

  Read more »

View all 3 project logs