Interview by Jari Williamsson, January 2005
Chris has worked as a Finale developer for almost 12 years. His software engineering specialities include MIDI, Graphics, and the Mac platform. Here he discusses developing Finale in general and the OS X platform in particular.
What's your background?
My background centers on math, computers, and music. I have a great love for all these areas. The start of my math career goes way back to 8th grade when I was enrolled at a special math program at the University of Minnesota. This naturally led to getting a BS in Mathematics from the University of Minnesota and graduate work in the Ph.D. program at the University of California, Berkeley. My mathematical interests back in those days were in areas like real analysis, complex analysis, differential equations, chaos theory, etc. I really enjoyed mathematical problems that lent themselves to creative use of computers too. One of my favorite applications of all time is Mathematica. What a program!
Throughout my academic career whenever possible I tried to focus on mathematics projects that were either computer and/or music related. I once interned at the University of Minnesota Geometry Center. I was working on some algorithmic composition projects and little did I know then that the NeXT and Objective-C I was learning then was going to come back 10+ years later in the form of Mac OS X. I was going to double major in mathematics and computer science, but the computer department, shall we say, was having some problems (seniors unable to take the classes they needed to graduate, etc.) and it made more sense to just graduate and move on.
On the music end of things, I was blessed to have been raised in a very musical family. Both my parents were music teachers and performers, and my two sisters were great on piano, violin, and singing. I was teaching piano to beginners in my mid-teens and performing in my parents "wedding band" at around 13 or 14 years old. A co-worker Trey at MakeMusic had a similar experience growing up gigging with the parents and it’s fun to talk about those days. I had been playing piano since about 2nd grade but I played keyboard bass in the wedding band. I think it was playing keyboard bass at this early age where I developed the ability to "play by ear".
During these years my dad and I were into everything MIDI, getting into it close to the time it was introduced in 1983. I loved hanging out at LaVonne’s music store to play with all the keyboards. The first MIDI keyboard we purchased was an Akai AX-60. I was getting into sequencing too with Doctor T’s software (yes this was before my Mac days). This started the “bug” that would later become my career.
I was classically trained on piano in those earlier years but by late high school years my interests were moving to jazz, pop, improvisation, etc. It was around my first year in college that I purchased my first Mac too. And to this day, it was still probably the most expensive one I ever purchased: $3000+ for a Mac SE30! I hear they make great fish tanks now. I played piano in one of the jazz bands while at the University of Minnesota and also performed with many bands throughout those late high school years to the present. One band, SoUlution, was especially notable in that we actually completed our own CD (the guitar player and I built the studio, wrote the music, produced the CD, etc.) and received some airplay on local radio stations. One of these days I plan to finish a solo piano album, maybe the first one will be a Christmas CD. Maybe I will even sing on it now that I have been doing more of that with my church choir. Today being the pianist for our first service and music director of our praise team at the second service keeps me busy musically, along with playing at weddings and subbing for local groups as needed.
How long have you been with the company?
I took a year off from graduate school that has now turned into about 12 years off. I married my high-school sweetheart and got this great job working at a music company in the Midwest of all places. I had always had an interest in music software and to find a company so close to home was great. I met some people from the company while gigging at a local bar/restaurant/lounge. It was Wednesday night jam session where people would sit in with us (including one time Dennis Green, former Minnesota Vikings Head Coach) and we started talking music, computers, software, etc. I think 5 days later I was working there full time, and it’s been almost 12 years now.
How would you describe the evolution during these years?
When I first started at Coda Music Software, as it was called back then, I started on what was then known as Vivace. Personally it was an “evolution of learning” for me. It was all new tools, new development environment, new (well first) version control software, etc. I was a “Think C” guy and they were using MPW (Macintosh Programmer’s Workshop). About 6 – 12 months later I started working on Finale. There I felt much more at home as we were using Think C back then.
Those early years were really interesting. I think Finale 3.0 was still in the works at least on Windows, and we were still living down the reputation of being hard to use. I think we have evolved extremely well in this sense. But not only have we gotten more easy to use, we have maintained a lot of the deep power that lies within Finale. I personally feel this is what does, and can continue, to set us apart from the competition. As a developer (and one with much concern about UI issues) I think the challenge for us is to give a lot of power, but then make it work in such a way that the power doesn’t get in your way when you first open the box. Have sensible default behaviors. Hide some of the more esoteric features. And so on.
Some like to call me the MIDI guy around here. I have lots of experience using non-notation software (Digital Performer, MasterTracks Pro-yikes what happened to the OS X version of that, Band-in-a-Box, Vision, Metro, Cakewalk, etc.). I mention that because this is another evolution that has been happening over the years, and one I hope continues. On the spectrum of music software where you have notation on one end, and non-notation on the other, we have seen a continual improvement by the non-notation programs (sequencers, auto-accompaniment software, etc.) in doing notation. I know a lot of guys that will throw together those quick horn charts out of their sequencer. I admit I’ve done it too. However, I do not think the notation software packages have progressed as fast in doing non-notation like activities (recording, MIDI editing, digital audio, etc.). But we have made some strides and I hope to see more of this in this future.
What's your job at MakeMusic?
Software Engineer. Besides the obvious Research & Development activities associated with creating new features in Finale and maintaining it, my areas of focus include MIDI, Graphics (CoreGraphics, QuickDraw, PostScript, GDI, Illustrator, etc.), Mac OS X/Mac OS technologies, and cross-platform engineering issues.
Which development tools are you using nowadays to create the MacOSX version of Finale?
We are using CodeWarrior 9 now, although 2k4 and 2k5 were built with CodeWarrior 8. I have used Xcode for quite some time now (I used it back when it was Project Builder and in fact, I had vaguely remembered Project Builder and Interface Builder from back in my days with the NeXT). Xcode just keeps getting better and better. I really like the distributed build feature. I have never seen Finale (our internal Mach-O build) compile so fast before. I usually have Xcode running for at least the Help system. And you may have noticed at least one .NIB file in 2k5, so yes, we are starting to use Interface Builder more too. We still have Resorcerer 2.4.1 for all other resource editing.
When making a feature in Finale easier to use, do you believe the most time is in research or in actual software development?
It really depends on the feature, and it can vary drastically. If we think of the research as the design work then some features are so obvious to design and clearly the development side is where the effort is (unless you get lucky and it drops in within a day). Some features on the other hand are fairly easy to implement but trying to get everyone to agree on HOW it should be implemented in the UI, etc. can be a challenge. On average though, I would say that most of the time is in the development. If we think of research as “engineering” research, then having that kind of work already done surely speeds up the total development time. In other words, if you already have a grasp of how all the pieces work independently, then putting it altogether usually is a much easier task. Or at least you have done your research to know it is a feature that will have to wait until another time.
Do you use Finale yourself (outside work)?
Yes! Although not as much as I’d like to. It seems that over the years there has been less time for such creative endeavors. Mac OS X might have had something to do with that over the last 4-5 years.
I have used Finale since the 1.0 days. I still remember my dad coming home from a conference at Paisley Park Studios and saying, “Wow, you have to see this cool program that notates what you are playing from your keyboard. I think they called it HyperScribe.” My dad then bought a Mac and I haven’t turned back since. I have used Finale to score horn parts for bands I have played with over the years, or to write out parts for myself. I have composed with Finale. I have done some engraving over the years too, including building some custom fonts for Finale. More recently I have made heavy use of the “Save As Audio” feature to create practice CDs for the choir I lead at church. It saves lots of group practice time when people can do some of the homework themselves outside of the normal rehearsals. Sometimes I even get to demo or teach Finale. I once did a presentation at the Minnesota Educator’s Association dealing with music technology in the classroom. Although some would say don’t you get enough Finale at work, and there is some truth to that, I find it very rewarding to not only be an engineer of the product, but to be a user as well.
Was the MacOSX port a bigger project than you first estimated?
As part of being able to call myself a Macintosh software engineer I felt it was very important to jump in early on OS X. That is where my 4-5 year estimate came from. I liked what I saw early on in developer previews and what I had seen from various keynotes. I had a gut feel that the legacy code in Finale was going to be difficult to do by anyone’s definition of quickly.
By the time the company was ready to jump into OS X, I already had a grasp of what the big issues were in relation to Finale: for example, Printing, Fonts, Text (drawing, ATSUI ["Apple Type Services for Unicode Imaging"], lack of XOR-ing text, rotated text had we not moved to ATSUI), Plug-ins, MIDI, etc. Somewhat of a surprise was some of our cross-platform GUI code, which really gave us some headaches. And there were those things that should have been easy which were not, menu handling via menu commands comes to mind. Of course, some of these areas came together really nicely. MIDI and plug-ins come to mind (although we still need to divorce ourselves from the Dialog Manager with Plug-ins). Other areas were troublesome, fonts!
"In general was it bigger than you first estimated?" I suppose yes. But anytime you have a whole bunch of individual estimates that add up to greater than an order of months, I am not sure how accurate the estimates can be. I recall some Apple documentation mentioning it TYPICALLY taking a couple of weeks to Carbonize. What a joke! Tell that to the people at Digital Performer, Band-in-a-Box, Quark, to name a few latecomers. We are obviously not a TYPICAL application either. Apple was expecting a lot from developers (although having the Carbon path was much better than what was initially being proposed by Apple), for example, move from FSSpec to FSRef, move from pascal strings to CFStringRefs, move from QuickDraw text to ATSUI, move from QuickDraw to CoreGraphics, move away from generating your own PostScript to CoreGraphics, move away from MIDI Manager/OMS/FreeMIDI/Finale MIDI Driver to CoreMIDI, move away from Dialog Manager to something else (including NIBs), move away from flat applications to packaged applications, move away from Controls to HIViews, move away from WaitNextEvent to RunApplicationEventLoop, move to CarbonEvents, and so on, and so on. Of course, not all of these were in the first OS X release of Finale or were strictly required for it, and some of these “moves” are still taking place today. You can see how this time can quickly add up. Not to mention the fact that you want to add Finale specific features.
I have seen quite a few users saying that the OSX version of Finale 2005 is slower than the Windows counterpoint. Is this caused by the fact that the move to the OSX architecture is not "complete"?
I suppose that all depends on what your definition of "is", excuse me, "complete" is. If we would have moved to every possible new OS X technology, we might have gained some speed somewhere. Overall though, I think we took care of the hot spots in terms of OS X related issues. If I had to guess, most of the performance gains we can expect to see will be related to Finale issues, not OS X issues. That doesn’t of course fully explain the discrepancy between the Mac and Windows version. Moving forward, there are surely things we can do to help improve speed from an OS X technologies point of view (for example, CoreGraphics support for drawing to screen, currently 2k4b and 2k5 use CoreGraphics for printing only).
A couple of other comments on performance. There were some changes that were made to get around using XOR drawing for example that may have caused speed degradations, but those changes were made on both Mac and Windows. Also, the change from using QuickDraw to using ATSUI for text rendering at first caused massive speed hits in our internal builds. We of course could not ship that way and eventually got the text rendering on par with the old QuickDraw support for the first OS X release of Finale. This is one example of those cases where we tried to "complete" the move to OS X in a given area.
What does the move to OSX mean from a cross-platform perspective? For example, are the "palette" of cross-platform user interface elements now larger?
They are potentially larger. OS X for example has support for a true combo-box, whereas in the past we implemented that with an edit field and a popup menu. Of course coming up with cross-platform UI elements has always been an important issue for Finale when you are dealing with over 400 dialogs! This reminds me of another point. Interface Builder has so many problems importing ‘DLOG’ resources and as we have been making the move to NIBs, this has been a real headache. Most people say, well just deal with it or do it by hand, etc. Then they hear we have over 400 dialogs. Ouch!
Another interesting thing happened in the move to OS X that is sort of related to this question. In some cases we had to sacrifice some of our cross-platform code to make things work under OS X. It was a trade-off between cross-platform conveniences vs. “how long do you want to wait for an OS X version”. Moving forward we hope to, of course, gain back some of this lost cross-platform code. I should note also that I am not proposing that all of the Finale UI code be cross-platform. The code that can be, should be. But the “framework” of cross-platform code should easily allow us to support platform specifics. We did get some of this in the OS X version, like Application Services support, Unicode/long filename support, inter-application MIDI support, .midnam file support (if you have the files from some other source), etc. Other platform specifics I’d like to see in Finale on Mac include AppleScript support, AudioUnit support, spell-checking, singing lyrics, etc.
Do you think Carbon is a better choice for Finale than using Cocoa? (Carbon and Cocoa are the 2 main development "routes" for OSX development; Carbon resembles the old OS9 programming syntax while Cocoa is an object-oriented programming interface.)
It was a better choice for us to get to OS X relatively quickly (faster than switching to Cocoa). I haven’t played with Cocoa enough to give a firm answer to this. My gut feel is that Carbon will continue to be the “right” choice for at least the next few years. I am not yet sure how our cross-platform code would be affected by such a move.
Do you think Finale as an application will benifit from an operating system such as OSX? If so, in what ways?
Absolutely. When Mac moved from 68K to PPC way back when, I remember saying “wow” to the speed. With the move Mac OS to Mac OS X, I have been saying “wow” again, this time to the stability. My home Mac maybe gets restarted once every few months, usually because of installing something. Long gone are the days of crashing an app, not trusting anything in OS 9, restarting and waiting for minutes, etc. You know the routine. The protected memory of OS X is awesome. The CoreAudio and CoreMIDI technologies have been great too. Finally MIDI supported at the OS level!
Are there any issues (from a Finale developer's standpoint) that now become easier in OSX than in OS9?
In my daily work, when CodeWarrior crashes or Finale crashes in CodeWarrior while debugging, it’s nice to know that usually all you have ahead of you is a CodeWarrior restart, instead of the restarting the machine! Saves a lot of time (and headaches) throughout the day.
Protected memory also helps us catch a lot of memory smashing bugs a lot more quickly. In fact, the OS 9 versions of Finale 2k4, 2k3, and maybe earlier (it has been so long ago…) benefited from those earlier experiments with OS X. I am pretty sure I fixed a dozen or so memory smashers in those versions because of building and testing in OS X.
Xcode has been useful for at least the help system.
Unicode support should be easier now that we only need to worry about OS X.
The debugging tools are wonderful under OS X too (Quartz Debug, Shark, Spin Control, etc.).
I am sure there are other issues. In general, I am happy to be on OS X. When we were working on Finale 2k4 we would occasionally have to go into OS 9 to fix something specific to OS 9. The difference was night and day!
Do you believe the actual Finale software development benefit from meeting/talking other users and/or see how they use the product?
Most definitely. You can really relate to what they are saying. If I meet a Finale user for the first time, I usually let them know I am a Finale user too, but I don’t mention I’m a Finale software engineer immediately. Doing that has a tendency to turn the conversation into a “can’t you just add this” or “can’t you just fix this” type of conversation. Rather, I like to explore where they think both the strong and weak points are in Finale. Sometimes I am able to help with something they are having trouble with and occasionally I’ll learn something new. Also, many times users will ask for a given feature X. Yet when exploring what they are really asking for, especially on a user to user level, you quickly find that what they really needed was Y and Z. This type of insight is invaluable. In the end, whether they know I am an engineer on the Finale team or not, they usually end the conversation with things like “thanks for all the great work” or “I couldn’t do what I do without Finale”. Makes the career very rewarding to hear things like that!