The long journey, part 3

I didn’t really understand the idea of immutable data before my project collapsed.

The worst design flaw was a concept I called Validators (in itself a misnomer). A project could apply one or more Validators, where each would improve the note picture in some way. One to make beaming, one to split long notes crossing bar lines, and so on.

And the killer feature: these Validators make their changes directly in the data model.

If the user accidently inserts a 128th note, the rest of the piece moves a 128th forward, and all of the notes are reformulated to match beats and bar lines. In the model.

When the note is deleted, another validator is supposed to reformulate the notes again, and hopefully restore the previous state. But for some reason, small errors tended to accumulate and eventually make the score totally messed up.

With unit tests, it might be possible to debug and correct the errors. At least up to a certain point.

But the killer feature was my wish to make variables, available to insert at several places in the score, possibly transposed or otherwise transformed. This turned out to be so much at odds with the chosen model, that I finally abandoned the project and started over.

Now using a more functional approach and Test Driven Design.