Apple has been busily working to 64-bit-ify all of the frameworks they plan to continue supporting into the future (Snow Leopard and beyond). However, QuickTime is scheduled for some nice Cocoaification, so it didn’t get much 64-bit love. QTKit, the 64-bit impostor, pretends to be the 64-bit way forward, but unfortunately this is far from useful.

QuickTime is all C function stuff, rather verbose and boring. It’s also 32-bit only. The 64-bit front end on it is a framework called QTKit. However, 64-bit QTKit is little more than an impostor that secretly makes things messier during the 32-to-64-bit transition. (more…)

Cocoa’s NSSound provides a blindingly simple way to play back audio asynchronously, and even provides some metadata and control over how the audio is played back.

It uses the default sound device, by default. It gives you the ability to change the output device.

According to the documentation:

- (void)setPlaybackDeviceIdentifier:(NSString *)playbackDeviceIdentifier
	
Specifies the receiver’s output device.
	
playbackDeviceIdentifier
    Unique identifier of a sound output device.

That’s it. What is the “Unique identifier of a sound output device”? What format is this “Unique identifier”? How do I get a list of the “Unique identifiers” of the available output devices on my system? (more…)

In the wee small hours of this morning, Kineme Interactive Media released its first commercial product, QuartzCrystal.

QuartzCrystal is an offline renderer that turns Quartz Compositions into portable QuickTime movies. It supports 3rd party plugins, as well as patches that do not work in safe-mode-only environments (such as QuickTime Pro). It also supports software scene antialiasing, so if you have a Mac with plenty of RAM and a hard-core video card, you can make spectacularly beautiful renderings of your plugins, effects, and compositions.

Beside QuartzCrystal, the only other product that renders and encodes compositions to movies is Apple’s own QuickTime Pro, which doesn’t support plugins, unsafe patches, or antialiasing.

In the year that has elapsed since I failed to explain why I was using PINE for email, I’ve switched to Apple Mail. Don’t ask.

Well, it’s been alright, but much to my regret the improved latency due to keystrokes only traveling around my local machine — instead of through the interweb and back as was the case with PINE on a remote machine — makes it almost justifiable. Almost.
(more…)

Lately I’ve been working on integrating (or, more accurately, attempting to integrate) the Python scripting language into some plugins for an application we develop plugins for. We’ve wrapped many libraries with varying levels of success, so this one wasn’t going to be much different. Or, so we thought. (more…)

People like their applications to work. Even better, they like them to work, even when things change. For the WinTel world, this isn’t a big deal (Vista aside ;), because the underlying CPU architecture hasn’t really changed, from a program’s point of view, in the past two decades. Unless you have a weird program that’s designed for AMD’s 3DNow! instruction set and you switch to an Intel CPU, or perhaps an application designed for a more esoteric old SIMD architecture, your application should run just fine (as long as your Operating System is ok with it).

Mac OS X doesn’t have the luxury of working on the same underlying CPU though, so things need to be handled a little bit differently. The solution Apple came up with was (more…)