Reflections on ObjectiveMax


A couple of years ago I got on an Objective-C kick.  In the process I created ObjectiveMax, an open-source framework for writing Max externals using Objective-C.  The goal was to create the easiest way possible to write objects for Max/MSP with minimal amount of “decoration code”.

My feeling is that it has been under-used by the community as a whole.  Reflecting, I think I know (at least partially) why…

I had intended (and even started) writing all of Tap.Tools 3 using ObjectiveMax.  The problem was that getting it to work on Windows, and then keeping it working on Windows, was beyond onerous.  I eventually decided that my personal sanity could not be tied to the inner workings of the GNUStep project.  In the end only the tap.applescript object is using ObjectiveMax.

A lot of people writing Max objects think about cross-platform compatibility.  Objective-C, and thus ObjectiveMax, do not easily provide this.  So that’s the first problem.

The second problem is that ObjectiveMax was initially licensed in a fairly unfriendly manner.  It took a dual-licensing approach similar to the one used by JUCE: GNU GPL for open source people, and pay money for a closed-source license.  While not an impossible license, there is enough in there to annoy and offend everyone.

There is a third problem too, ultimately caused by the first two problems: lack of adoption or popularity begets a lack of adoption and popularity.  No one uses it because no one else is using it.

If it’s Broke, Fix it.

I’m convinced that for Mac users this is the easiest way possible to write objects for Max/MSP.  So how should these concerns be addressed?

First, I just changed the licensing of ObjectiveMax to a single new BSD license.  This license was first suggested to me for ObjectiveMax about a year ago by Niklas Saers.  The more I’ve thought about it, the more sense it makes.  This makes the framework free and open-source to everyone for virtually all purposes, including commercial purposes.

Second, I don’t plan on rushing in to making ObjectiveMax work on Windows.  But I’m more than happy to help anyone who does want to get it working.  I’ve been keeping an eye on the Cocotron project for a while now, and I’d be very pleased to see people join the ObjectiveMax GoogleCode project to work on using Cocotron to get a version working for Windows.

And the third problem?  Well, it would be futile to try and control the adoption of the framework.  It’s open-source, and if people think it is worthwhile then they will use it.  Hopefully people will join the project and contribute to it.  One thing that is true is that I have not promoted ObjectiveMax much, and I’ve never taught any seminars using it.  This type of activity would be almost certain to increase the project’s luster and adoption.

… and if You Can’t Beat ’em …

As previously mentioned, I ended up giving up on using ObjectiveMax for Tap.Tools 3, but solely for the reason of cross-platform compatibility.  A lot of what I learned, and learned to love, about Objective-C made it into the C++ library that Tap.Tools 3 and Jamoma use.

The TTBlue project (a.k.a the Jamoma DSP Library) incorporates reflection, message passing, and other aspects of Objective-C but in a C++ context that functions on both the Mac and Windows.  This project is very active, and the resulting code with which you write objects is getting progressively cleaner.

Or, as a card from Brian Eno’s Oblique Strategies states “When faced with a choice, do both.”

About this entry