Beams & Ligatures

Feels like the principle of iterating through the array of elements to be drawn now needs to become more comprehensive.

When drawing a note, you draw it’s stem and then any tails needed, except if the next note in the array has it’s ligatures (aka beams) extended back to this notes tail.

Also you don’t draw a notes tails if it is to extend back to the previous note but you do need to know what type of note the previous one is and where it’s stem is.

So a note needs to know the properties of the note to it’s right, and to it’s left in order to draw itself.

Now this light bulb has gone on, the approach of adding context through parameters to the paint() method could get quite clumsy. It may be better to allow each note access to read the manuscript it’s part of.

Following this approach would mean a note would fix up to the array of notes, find out it’s index in the array, then use that to access it’s neighbours. This could be quite expensive in terms of CPU cycles to perform array lookups as it’s a serial scan through an array to find it’s index.

Should we worry about CPU cost in this day and age? How much will performance be dragged down by if there’s 200 elements in the array?

A more performant approach would be to provide the references to the next and previous notes, and staff elements (you need to know if your neighbor is a bar line as that changes your drawing behavior too). This is what’s been implemented in the code today, for now, using some funky referencing while performing a single scan of the staff elements array.

My remaining concern is what else will we discover needs to be provided at paint() time in the way of context that will continue to extend complexity here? I wonder how long it will take me to get up to speed on this piece of code in 3 years time between this blog, documentation and source comments!