Recent experience has taught me that traditional design approaches such as figuring out the data path requirements is a good way to approach figuring out how to implement functionality in the component. Firstly, we need to figure out which object is responsible for drawing these. Of course, it’s view in the component that will trigger this.
Our options seem to be:
- Store an array of ties in the data model and have the view do the drawing at it’s level. If we only have a central list, this would mean the controller needs to create actions to build and amend the list, and also ensure if notes were deleted that were referenced in the list that we don’t break the data integrity in the model. The controller could use a keystroke on a selection to mean check the array, if tie exists then delete it, if not then create it.
- Have each note store a reference to the note at the other end of a tie it’s part of, and the second note in a tie is responsible for drawing the tie. The controller could work by taking a keystroke on a selection to mean toggle any tie between the first and last notes in the selection.
Another consideration is a tie could actually impact any future playback feature we build in and we want to think to the future, creating a good base now. If it’s an irregular grouping we need to know at the note level if it’s in such a grouping, eg ply 3 in the time of 2. I imagine playback will be executed by iterating the array of notes so the ability to ask the note if it’s the head of a tie binding could be useful. If it’s not an attribute of the note itself, it means an array scan of any central tie array for each note we process.
Doesn’t sound like a good idea from that perspective. Given we need to store an attribute which is unique to a tie, i.e. if it’s an irregular grouping, what’s the count,, e.g. 3, meaning 3 in the time of 2, 7 in the time of 6 and so on, it sounds like we need a class anyway. The tie class would store the head and tail notes of the class plus it’s irregular grouping factor. It’s probably appropriate that the tie knows how to draw itself. Whereever the drawing is triggered from, either at the component view level or while iterating through each individual notes draw routines, it’s good to separate that capability I think. Next let’s consider a note may be part of more than one tie, it’s not seen often but it’s possible, so need to cater for it. This suggests the concept of an array of ties would be a good way to store this. Given we now have a class, then a list of them isn’t too hard to implement, the question that remains for me is do we have a master list of ties, or do tie lists exist only within the notes themselves. In the latter case the note class would have a list of ties that the note is part of. While drawing the note would iterate this list, figure out if it’s the tail in the tie partnership and if so tell the tie to draw itself. So certainly each note needs a link to the ties it’s part of – that allows it to delete the tie should it be deleted itself and we protect ourselves against orphaned ties – there’s a concept!
Lastly, the note, with it's list of ties which link it to it's partner note, needs to cater for when the tie crosses between staff lines. It will be able to detect this by checking the y co-ords of the staff lines each note connects to but it won't know if they're more than one line apart. We somehow need to either get it a reference to the list of staff lines or get the controller to prevent ties being created across more than two lines. This could be close to impossible, given the user could drag a tied note down a couple of lines.
May need to find that reference to the staff array. It could be passed through the paint() calls, as today's thinking also says we need to either pass the list of notes through or at least a reference to the prior note in the array, when a note paints itself. This is so it can figure out where to draw beams back to. Oh, apparently beams are called ligatures too - hadn't heard that before but then again it's only the RSPBA exams I took on theory, nothing more comprehensive!
And something else, what I've been calling accidentals are better referred to as grace notes, as accidentals only seem to affect pitch - not something us simplistic drummers can do on a kevlar high tension surface...