Things are starting to move again in music-land and I’ll have some great news soon. In the mean time, check out my new project, the Lessonator app.
I was recently asked by a fellow developer to relate my experience of writing multi-platform graphical applications with ObjectiveC++. This has become a very important topic, now that Apple has made it clear that they were not going to improve the Carbon framework and that everyone should use Cocoa/OjectiveC.
Writing ObjectiveC++ applications is straightforward, but there is no up to date documentation on the process. Generally, programmers want to use Cocoa/ObjectiveC for the UI and C++ for all “core” components. With C++, you get STL and a very large collection of well-tested code. In the end, although the object models in C++ and ObjectiveC are quite different, they can easily co-exist as they are both based on C and use common design patterns.
Main Objective C++ Documentation
This 2001 Apple release note is in serious need of an update, but it provides all the basic rules of mixing the two language.
Example XCode Project
The great time saver consist on finding a good example project. The Big Nerd Ranch provide this simple example where a C++ object is used to encapsulate the drawing code from within a Cocoa project.
Gotcha #1 – Embedding Method
The most basic decision that has to be made is how to actually represent the embedded C++ class: as a member object or as a pointer?
· CDrawing m_Drawing; // object or…
· CDrawing m_pDrawing; // pointer to object
Obviously, being able to embed an object directly would be awesome if the constructor and destructor were called automatically by the parent ObjectiveC view class.
This article as well as this one claim that this is possible using the latest GCC compiler. I’ve tried and it only works if the embedded class is very simple: no inheritance, and no member objects. This is useless for most applications, so basically, using a pointer is still best.
Gotcha #2 – Conditional C++ Includes
Every header file associated with an .MM file must start with something similar to this:
// ifdefs hide the C++ type from pure ObjC classes that import this file
Without this, the C++ in a header file will “contaminate” everything that #imports that header and result in a bunch of Xcode errors.
So there you have it. This is what I wish Apple would have put in a simple release note (together with *updated* example Xcode projects). Hope it helps. Let me know if you have further questions.
All songwriters have influences. For me it’s Sting, Seal, David Bowie, Tina Turner and Motown (yes, I know…). They all make me say: “Gee, I wish I’d written that!”. Writing software is very similar to writing songs: they both start out as totally unorganized ideas and end up on a nice little shinny disk with a sticker price. Derek Silvers, founder of CDBaby wrote a piece entitled “Programming is like Songwriting” about the parallels between these two activities.
While writing SonoGraphx, I tried to think which software products have had a major impact on the way I approach software design. I’m a visual guy, so I’ve always been more interested in graphical GUI than clever text mode utilities (i.e, no vi or emac for me thanks). Yes, I’m a sucker for good graphics. For some reason, most of my influences are on the Mac. I wonder why…
So here’s my list:NextStep
I have long been an admirer of Steve Jobs’s NextStep operating system/GUI. In the 90’s I used to have an add-on (WinDock) that would turn Windows 3.1 into a NextStep look alike (the Mac was just not powerful enough for 3D development). For awhile Next looked a dead company until apple purchased them and turned NextStep into Cocoa.
After long days working on Windows, I used to open my Mac just to admire the UI and wish I had the time to develop for it. It’s so good, we often forget it only has 5% of the market. Sure, it’s not perfect: most of the graphical aspects of OS-X (the dock, the beach ball, the candy bars) are more eye candy than useful. However, I feel that UI is like architecture: since you’re going to spend a lot of time in it, it better look good.
Delicious Monster Delicious Library
Will Shipley got kicked out of Omni, the company he co-founded when he finished college. So he wrote a new product that became one of the biggest hit in OS-X world. The beauty of Delicious Library is that it basically does one thing: scan bar codes. Yet it does it in a way that does not require a manual: you just put a book or CD in front of your iSight and move it until it recognizes it. It reminds us that the best programsis are the one that look like magic tricks: you’re not sure how its done, but it works and it’s cool.
This combinaison of flashy interface and (very hyped) marketing now has a name: Delicious Generation.
This is the only music product that could figure out just by looking at it. If you’ve ever operated a Mackie mixer, an EQ and a compressor, you know how to use it. Brillant!. The whole rack interface makes so much sense, you wonder why it’s not everywhere (maybe because only audio/video professionals and use racks…). The greatest aspect of this product is to use the TAB key to “turn around” the rack to reveal the patch chords. They thereby solved one of the most complicated aspect of using a DAW: making sense of the I/O configuration.
How can you not be influenced by something you use everyday? Most of us use less than 5% of their features, yet neither application looks “bloated”. Although controversial at the time (early to mid90’s), I totally agree with Adobe’s decision to use the same UI concepts for both programs. In a way, you only need to learn one to become “adequate” at the other, which is the promise of standardized graphical user interface. I discover something new everytime I use them.
This is an excellent example of why it is worthwhile to spend a little time on the visuals. This app originally looked bland, until they hooked up with WidgetMachine and gave it this totally cool look.
The SonoGraphx project is turning out to be quite different from what I had first envisioned. My initial 2005 UI sketch was about keeping all my song ideas in one place:
I coded a prototype only to realize that while it looked good, it was totally unpractical, and therefore useless:
The problem is that in real life, most of my songwriting time is spent capturing organizing my ideas. Then, when I have enough ideas, I sit down and try turning them into finished songs. These two tasks are quite different and cannot be addressed with the same interface.
A little informal survey confirmed to me that I wasn’t the only one working in that fashion. Indeed, this is how most songwriters work: we all carry a notebook or a portable audio recorder to capture ideas immediately.
With this in mind, I rewrote the prototype to operate in two “spaces” Ideas space and Songs space. In Ideas space, all I want is to accumulate ideas into little “piles” that I can then select and bang into complete songs in Songs space.
Here’s Ideas space:
Here’s Song space:
Stay tuned for future developments….