
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.
lion mclionhead
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.