My OS X Programming Blog

Just thought I'd write about something other than programming today. Amazingly, this rose is still blooming in my front yard. The snow we got a few weeks ago must have delayed it.

Wild mushrooms spontaneously appeared in the damp corner of my backyard. They may look pretty now but wait until they start to wither.

Baked some cookies this afternoon. Cookies are so easy to make and they bring a little bit of joy.

My recipe is quite standard (see this one, for example). I usually only make a batch of 15 cookies. So here's what I use.

1/2 cup magarine

1/2 cup brown sugar

1/2 cup white sugar

1 egg

1 tsp. vanilla extract

3/4 cup flour

1/2 tsp. baking powder

1/2 tsp. salt

1 1/2 cups large flakes oatmeal

1/2 cup sliced almonds

1 cup raisins

Mix ingredients in the above order. Scoop golf-ball size dough onto cookie sheet. Flatten with fork. Bake for 10 minutes in 350 degrees Fahrenheit oven.

Some tips:

Use ingredients at room temperature.
Cream sugar and magarine well.
Use parchment paper.
Don't overbake.
Try dry cranberries in place of raisins.

CoreMIDI MIDI End Point Names

Thursday October 2, 2003

CoreMIDI is probably one of the least “Mac-like” parts of the OS X API. Considering its origin (OMS), this is no surprise. For instance, the Documentation makes a recommendation on how names of MIDI end points (sources and destinations of MIDI messages) should be presented to the user. Because it is inexact, different applications can follow this recommendation and still display names differently. They'll also fail to eliminate duplicated names completely, which is what the recommendation attempts to do unsuccessfully.

There is room for a better library here. All a MIDI application really cares about is the list of sources and destinations it is using for the current document. There must be a way to edit this list and to store and retrieve this information from a file. Perhaps at a higher level, the library can provide an “ensemble” abstraction: the set of instruments for the current document. Each output instrument probably corresponds to a destination, a MIDI channel on that destination, and a program change to specify a patch. The library may need to handle midnam documents to be able to present the patch names. Ensembles should be persistent. And there should be a library function for editing the ensemble, much like the “Instruments” window in Opcode Vision. If there is a set of library routines like this, all MIDI applications will handle the selection of instruments in a uniform fashion.

The use of unique ID's in CoreMIDI instead of string names is another unpleasantness. I'll need to think about how to deal with this next. In the mean time, I have written this sample program for printing the current set of sources available. Some of the code was already in SysExSenderX, but now it correctly prints the names of virtual sources and destinations, and it makes use of a callback procedure to print a new set of sources whenever some are added or deleted from the system.

Homemade Cocoa Frameworks

Wednesday October 1, 2003

More strangeness.

Apple's AboutBox sample code, which demonstrates the use of frameworks, is written in Carbon. I converted it to Cocoa in this project. Debugging works correctly for the “development” build style. One can single-step into lines of files in the framework, and so on.

Then I separated the framework and application into two projects, resulting in this archive. When it runs, the application needs to locate the dynamic library in the framework. This can be achieved either by setting the environment variable DYLD_LIBRARY_PATH, or placing a symbolic link in the application's directory. Interestingly, debugging works correctly as before, despite the presence of prebinding warnings.

So my conclusion yesterday that prebinding prevents stepping into framework source files is wrong. One difference is yesterday I was only using Foundation and today I'm using Cocoa. I can't think of any satisfactory explanation for this. Anyway I can use frameworks now.

Project Builder Documentation

Tuesday September 30, 2003

I skimmed the Project Builder documentation today. I figured if I'll be spending the next few months writing programs in it, I might as well get to know it better. I learned a few tricks: command-double-clicking a class or variable name to get quickly to its definition, turning on and customizing tab indentation in the editor, using the class browser, and searching the documentation in the find panel.

I was also interested in learning to create my own frameworks, since I want my MIDI library to be separate from my MIDI applications. That's not too difficult to do. However, I can't seem to get the debugger in Project Builder to step into a framework that isn't part of the current project (this is possible with command-line gdb). If that's the case, the framework and the application will need to be kept in the same project while the framework is being tested. I'll need to investigate further.

[The following morning: resolving the prebinding conflicts by adding the linker flag -seg1addr 0x10000000 also solved the debugging problem! It's not entirely clear why, even after reading the whole AboutBox example and creating an embedded framework as prescribed. That's the futility of cookbook-style documentation, I suppose. ]

MIDI Programming on Mac OS X

Monday September 29, 2003

Here's a list of resources for people who are thinking about writing MIDI programs on the Mac OS X.

The CoreAudio SDK can be downloaded from Apple Developer Connection.

You may want to take a look at Pete Yandell's PYMIDI Framework.

You may also want to look at CMU's PortMIDI.

While I was debugging my MIDI program, I found Kurt Revis's MIDI Monitor to be quite useful.

Chris Reed also provides a few sample programs.

You will also find Apple's Coreaudio API mailing list, especically its archive, very useful.

This is Doug Wyatt's resources page. I think he used to work for Opcode Systems on OMS and now works for Apple on CoreMIDI. That's why much of the strangeness of OMS is now in CoreMIDI :-).