Some time back in 2013, I had an idea of creating a web site with a catalog of all classical composers and all of their works. It might be a reality one day, but a tiny subproject took all of my attention: I wanted for users to be able to enter music quotes of themes from the works. So at first, I created a javascript project that made a decent display of the note samples.
Then I heard about Typescript and converted all my code to that. I the process, I found several previously unnoticed logical errors in the code (like wrong argument order in function calls).
This attempt was making heavily use of Gang of Four Display Patterns. Everything is abstract and loosely coupled, and visitors and factories and other patterns are all over.
In the following years, I extended this to a rather cool application, where semi-advanced features as tuplets and grace notes became implemented. Also, the user interface included a clone of Finale SmartEdit mode to edit music, and dialog windows to edit stuff like keys and time signatures.
It was also a learning process. Along the way I learned new stuff and refactored code to use that. Design patterns, Typescript, linting, coding to interfaces, npm projects, separation of concerns, Angular, unit testing were some of the concepts introduced along the route.
The project stalled when I introduced variables – music snippets to reuse throughout the score. Some design flaws turned out to be irrepairable (well, you can try it out for yourself, since the github repository unfortunately can’t be deleted, but will be available forever here: https://github.com/UtMiLa/jMusicScore).
The most important flaws were the half-hearted Test Driven Development and the missing immutability.
To be continued…
Leave a Reply