Core MIDI - A poster child for my early Apple experiences

Submitted by Brian Marshall on Fri, 2005-07-29 02:00. Core MIDI

I've begun writing some Core MIDI code today. I'm still writing some test spikes to explore the API. But so far using Core MIDI is a microcosm of my Mac experiences so far.

-The user part of Core MIDI is sweet. I picked up a MOTU Micro Lite interface for my office, and it installed incredibly easily. Drive installation on OS X is far cleaner than Windows. And once the hardware was up, the "Audio MIDI Setup" program was another pleasant surprise. It took mere minutes to set up my entire MIDI topology with nice graphical elements representing the hardware. It's obvious that Apple cares about Pro Audio users, and has done everything they can to make the user experience slick and easy.

-The API, on the other hand, is extremely poorly documented. The Core MIDI documentation, like most Apple docs, is merely a list of the functions and classes that are used in the API. This is practically useless from a bootstrapping point of view. I have found very little useful information on how to use Core MIDI on the apple developer site. Yes, they do have a tutorial on (how COre MIDI works, but it doesn't tie the API into the abstraction. This is typical of the state of Microsoft Developer documentation from about 4 years ago, but they've done a lot of work to make them better. Not perfect, but better. Tutorials and sample code are required to really get the API off the ground. Here's one area where Apple needs to learn from Microsoft, specifically the DirectX SDK team.

-XCode is just not ready for Prime Time. It's actually a good environment, but I've found one bug that just keeps on annoying me. My modus operandi while coding has always been to write a little bit of code and then compile and debug it to make sure it works. I'm switching to a "test first" methodology now, for all the obvious benefits. But in the old days "before developers wrote tests", I would test the code first with scaffolds and test calls before I put a function into place. It's the same idea, but nowhere near as formal. And when writing tests was "the tester's job", that was one way to get a similar result. But that means I often compile with syntax errors. I compile all the time, using the compile to check my grammar. I never expect the code to work the first time. XCode, however, doesn't handle missing braces very well. Try writing a function, then adding a couple of extra braces. GCC, at least for me, starts spitting out recursive errors messages. This hangs XCode, and I have to quit and restart. Not a long process, but a pain.

-XCode also does have good support for separating out sub-projects in a tree. By default, all your files for a project go into one directory. This just doesn't scale. I've worked around this by moving each sub-project into it's own folder, and creating a group for that folder. Then I add all subfiles relative to the group, and they end up in the same directory as the subproject. This looks a lot neater, and makes tracking changes much easier. Was that last checkin a test fix or some real code? Now I can tell by the location of the file. But it took about an hour of playing around with the default template projects, and then starting again once I'd figured it out, to get a basic skeleton that I could check into PerForce. Far too much work for what should be a basic operation.

If you know of any good Core MIDI tutorials, let me know. In the meantime, I'm poking around the API by writing tests to document what I learn. It appears that they've abstracted the sending of MIDI messages nicely, but have done nothing to abstract the messages themselves. Looks like another library I'll need to write.