Life

Just an update to let anyone reading this blog know that the project from my last post was put on the back burner for a bit while I worked out other things in life. More specifically, I've been looking into grabbing a job. I recently had an on-site interview with Facebook which went relatively well, but I did happen to stumble a little on the technical interviews. In a couple of days I'll be hearing back about that. Looks like a great place to work!

Anyways, back to the project. It's getting pretty close to release, so expect a blog post in the near future pointing to the repository. I'm mostly improving the documentation, and working out the workflow for release. There's a couple of design issues I have with the project currently, but I may push things to GitHub before I take care of those.

Keep checking back for updates!

-- UPDATE -- 

Looks like I didn't get the job. Unfortunately, my lack of experience played against me and my stumbling.

New Projects

It's been quite some time since my last post (this seems to be a regular occurrence, doesn't it?). Well, fear not, I still exist. Unfortunately the score editor project had to be put on the back burner for now, as I've picked up a real job (only a short-term contract), which leads into my discussion in this post.

Working on a real project has really helped me learn many things, but especially good design techniques. In particular, my project will be used as a plugin for an existing piece of open source software (Phon, a tool for phonological analysis). To not see the past few months worth of work go to waste, I've been given permission to take this project on as my own (it'll show up on my GitHub account eventually), so I'm really designing this to be something that's easily usable and extendable by others. In its simplest form, it's a framework for designing complex operations from simpler ones (think Quartz Composer, but more general).

Since I'm designing something that will be used by others, I really need to think twice about every decision I make. Some discussion points on my experience so far:

• I want my API to be final (in the Java sense of the word) so that people can depend on it (e.g., backwards-compatibility), but I still want the API to be extendable. I've implemented a simple extension mechanism that permits this freedom. Anyone can simply query an API structure for a certain extension, and if it exists they will get an instance of that extension to work with. Otherwise, they get a whole buch of null.
• Modular programming can be a wonderful thing for an API. When I started, I just had one massive project. When I chose Maven for building, I decided to move to a modular design. What I ended up with is a set of modules (e.g., API, GUI, XML IO) that are tightly coupled. Right now I'm working on decoupling these modules as much as possible and, soon enough, modules will depend only on the API module, which is the way it should be.
• I've never really designed anything modularly before, but what I've learned is that dependency injection (DI) is a beautiful thing. In particular, I make extensive use of service discovery to get implementations of what I need. I may eventually look into OSGi, but don't want to be bound to it, so I've abstracted away my service discovery mechanism so even it too is determined through DI.

It has been a fun time designing this API, and I'm hoping that within two weeks I'll have it completely modular, and ready to go for Phon. A couple of weeks after that, it'll be up on my GitHub. I'm really hoping it's something people will want to use, and if they do, a framework they enjoy working with!

Revamping The Data Model

When coding the core data model for the score editor, I tried my best to keep any view-related information out of it. This was in an attempt to follow the Model-View-Controller (MVC) architectural pattern. Unfortunately, what I've realized is that this separation is actually making my life more difficult. What I've come to realize is that in my own case, this separation doesn't even make sense.

Why? Well I'm not trying to create a core music library that can be reused by others (not anytime in the near future anyways), but rather I'm attempting to create a professional and free piece of software so that people can create, edit, playback, and print musical scores and tablature. Intrinsic to that purpose is the display properties of the various elements in a score. In other words, view-related properties are part of the data model.

As another teaser, here's how far I've gotten so far in the rendering process:

There's a lot of work to be done, but I was getting close to something presentable. The need to tackle the display properties of elements and somehow integrate this into the data model is my next step, and unfortunately that will take time. Right now I model only the very basic elements:

• Score
• Part
• Staff
• Bar
• Column (a single note / chord)
• Note
• Instrument

along with a few other small things (e.g., note bends, rests, grace notes). What I need to do is include other display elements in the model so that I can more easily allow the user to modify anything and everything in the score. For example, I should model a beam so that the user can change its slope. I should model the note head so that the user can change its size, color, etc. I should model the stem, so that the user can change its length. I would provide an automated system that will do its best to get the score as close as possible to what the user would like, but a "one size fits all" solution doesn't exist because everyone has their own preferences.

Oh the joys of designing a serious piece of software!