with your vanilla NSImageView…

referring to an image file within an Xcode project…

Holy Cow! An Acorn file? Does that mean I can use Acorn files directly in Interface Builder 3? Does that mean you’ve written an NSCustomImageRep that understands the Acorn file format? Does that mean I can use Acorn files directly in my Cocoa projects? And that means I no longer have to keep exporting these bloody files as pngs so I can use them in Cocoa, right? Will this give rixstep some ammunition to go apeshit insane about?

Yes! Yes!! Yes!!! Yes!!!! Yes!!!!! Almost certainly.

Not only does Gus Mueller generously provide details about the Acorn file format, he has even released the source code to his Acorn Quicklook plugin. This gives me everything I need to convince NSImage to load Acorn files.

You might well be asking yourself why. I was getting annoyed with having to constantly keep exporting original Acorn images as pngs or TIFFs so I could use them in Xcode. I’m prototyping a new application that uses a lot of custom UI elements. These elements are made up of one or more pngs, some of which needed a lot of tweaking and attention to detail to get right. Acorn is perfect for UI work (although it needs more than 2000% zoom! cough) but having to export as png (or another format that Cocoa understands natively) and manage two sets of images (original Acorn, exported png) was turning into a pain.

I’ve taken Gus’ QuickLook code and wrapped a small NSCustomImageRep around it. Very small. I’ve repackaged it up as a Framework so you can refer to it from an Interface Builder 3 plugin. This gives you the ability to do this:

[NSImage imageNamed:@"IAmAnAcornFile"];

You should be able to use Acorn files anywhere an NSImage is used. Just embed your Acorn files in your XCode project resources and refer to them by name in your NIBs or in code.

I’ve put the code on my public googlecode.com subversion repository.

I’m currently on the fence about whether it is a good idea or not to ship your application with Acorn images. It certainly makes sense to me to use them during the interface design stage of application development. Once the user interface churn settles down I should be able to finalize the images and convert them to pngs or whatever (keeping the originals of course).

A best of both worlds solution might be to make a little command line tool that can convert Acorn files:

#!/usr/bin/python
from AcornImage import *
# Everything else is an exercise for the reader.

And then automatically convert from Acorn to whatever during the Xcode build process. I might investigate this technique at a later date. But for now – have at it.

Toxic Progress Indicator should still be used on apps that need to run on 10.4, but I wont be supporting the class any more (not that it is really needed any support…)

Although the SpaceNavigator support six degrees of freedom, I’m only using two (Y axis for forwards/reverse and RZ for turning), that leaves plenty of room for expansion (perhaps hooking up a third motor to another controller axis).

Although the video doesn’t show it too well, the SpaceNavigator does allow for very fine grained control over the robot (as long as the robot has fresh batteries!). The controller is extremely sensitive and with practice the robot can be controlled quite delicately.

Currently only one axis is dominant at a time (that’s actually a preference in the SpaceController System Preferences screen) but it is be possible to control robot steering and speed/direction at the same time. I’ll be trying that out soon.

There doesn’t seem to be much in the way of Mac OS X APIs for controlling NXT via Bluetooth, so I’m putting my code onto my public subversion server and releasing it (like everything else in my public repository) under the BSD License. The code is Leopard only (although all I’m using are some Objective-C 2.0 features, such as properties and the new for loop). The code uses Cocoa bindings/KVC and has a rather simple interface:

robot = [[[CNXTRobot alloc] init] autorelease];
((CNXTMotor *)[robot.ports objectForKey:@"B"]).power = (int)(theMotor1 * 100.0);
((CNXTMotor *)[robot.ports objectForKey:@"C"]).power = (int)(theMotor2 * 100.0);

The sample NXT project relies on my ToxicWarped framework. ToxicWarped was originally created for my Geode project and is designed to help write simple but flexible Object Oriented protocol stacks.

The NXT code is barely a day old, so it is very rough and ready but I’ll be tinkering with the NXT and SpaceNavigator code over the next few weeks (in my spare time) but if anyone has a use for the code and would like to contribute back that would be fantastic.

Update: Couldn’t stand awful Youtube image quality any longer. Videos are now on amazon s3.

The software that comes with the SpaceNavigator is functional, but like a lot of hardware related software is rough around the edges. You can provide customised settings for specific applications or use global settings. You can set up macros to fire when either of the SpaceNavigator’s two buttons are pressed. Understandibly the SpaceNavigator will not appear to applications as a standard input device, so 3Dconnexion provide an API to allow 3rd party developers to use the device. This opens up a host of opportunities for 3rd party developers. The Space Navigator could be used in third-party applications as a jog wheel, kind of like the Griffin Powermate and also as a 2D scroll wheel at the same time.

This leads me onto Acorn, Acorn is Gus Mueller’s newest application. It is an awesome 2D image editor, with a healthy list of features. I consider it to be a “Photoshop for the rest of us”, and has quickly become my image editor of choice. Like Gus’ VoodooPad, Acorn also supports a plug-in architecture. This allow developers to extend the applications in ways Gus wouldn’t have dreamt of (although considering Gus wrote FlyGesture I’m sure he has some pretty funky dreams). I’ve created a plug-in for Acorn that uses the SpaceNavigator API to zoom and scroll around the image you’re editing. Rotating the SpaceNavigator causes the image to rotate (using the CoreImage affine transformation filter). This just touches the surface of the cool things you can do with the SpaceNavigator and an application that supports plug-ins.

Now for the money shots, two movies of the plug-in in action:

Source code for the plug-in is on my Google public repository link, I’ve also written a Cocoa wrapper for the 3Dconnextion API (required by the Acorn plug-in): link. My Cocoa wrapper provides a much simpler interface to the device, and also provides more functionality (such as emulating a scroll wheel). I’ll be working on the wrapper more in the future.

All this code is a work in progress and you will probably need to massage the Xcode project to get it to compile. You’ll also need the 3Dconnexion API (and of course a SpaceController).

And hey look – I’m blogging again!

Update: I got daringfireballed, so I’ve moved the movies onto youtube – quality sucks, but now the server seems responsive again. Links to source code fixed.

Update: Movies now on Amazon S3. Youtube quality sucks so much. (videos still on Youtube here and here).

The simple answer is I’ve stopped hosting my public subversion repository on DreamHost and have now created a Google Project for it. The project URL is:

http://code.google.com/p/toxic-public/

And the subversion root is here:

http://toxic-public.googlecode.com//

Google will be a lot more reliable than DreamHost ever will be. I also get bug tracking and easy user maintenance.

I’ll update the broken links when I get a chance.

Unfortunately adding the cell caused drawing of the table’s window to slow to crawl. The spinning beachball of death would often appear when I was merely resizing the window. After some quick experimented I narrowed it down to something within the ‘Discrete’ variant of the NSLevelIndicatorCell, the other variants had no such performance problems.

It didn’t take an expert in Shark to realise what was going on:

It looked like NSLevelIndicatorCell was perform an expensive gaussian blur per cell, possibly even for each discrete block within each cell. For a single NSLevelIndicatorCell that shouldn’t be a real problem, but for a whole table column full of them it could create major performance problems.

Some quick google searches showed that people had complained about poor NSLevelIndicatorCell performance before but failed to find a solution.

Switching to another variant of NSLevelIndicatorCell wasn’t an option, the ‘Discrete’ variant was just too sexy. So the obvious solution was to create a subclass of NSLevelIndicatorCell that posed as the real thing, but cached the drawing code of its parent class into NSImages. So I present to the the world the imaginatively titled CCachingLevelIndicatorCell.

CCachingLevelIndicatorCell is designed to pose as NSLevelIndicatorCell but shouldn’t require any other configuration. The class will only cache images for the ‘Discrete’ variant and will use a dictionary of NSImage objects to cache the drawing (one image per discrete value the cell can display). If any other attribute of the cell is changed the class will discard the cache and attempt to recache the drawing at the next opportunity.

Just so you can compare the differences in speed I’ve created two stand-alone test applications so you can compare the speed without CCachingLevelIndicatorCell and with it posing as NSLevelIndicatorCell. The binaries are checked into my public subversion.

Radar bug: rdar://problem/4601201

I’ve also branched all the test projects and the framework. You can find the branch here: branches/SequenceGrabber Stable. This branch is intended to be relatively stable, I’ll make sure the code can always build and run. If you don’t feel like dealing with the churn in the trunk then this branch is for you.

The easiest way to use the sequence grabber is just to add a CSequenceGrabberView to your project. The view supports start and stop actions so you can wire your user interface directly to the view. You can also access the underlying CSequenceGrabber object directly if needed. There are plenty of hooks in the code to add your custom functionality – CSequenceGrabber (and its children video and sound channel objects) sends many useful NSNotifications. I’m also going to make the code use Cocoa bindings as much as possible. That way you can use bindings and/or notifications as your need dictates.

I’ve improved the “QuadView” sample code to take advantage of Cocoa bindings support in CCoreImageView. One thing I’ve noticed is that the core image filtering just isn’t very fast. After two or three live video streams running through Core Image filters the frame rate drops rather dramatically. I will look into this further and hope to make big improvements if my code is actually the bottleneck. Or maybe it is time to just order that Quad G5 now that they’re available (one 2.5GHz core per video stream sounds like a great idea!).

If you are having trouble building the code – remember all projects require Xcode 2.1 (or newer, I am using Xcode 2.2 for development). Also you will need subversion to check out a full copy of the code.

Finally I’ve been really encouraged by the interest that my Sequence Grabber code has generated. I’m getting a few emails a week from people using it in their projects. I love hearing about the uses people are putting the code to and encourage anyone using it to append a comment to this blog posting.

This is what happens when your cat wakes you up too darn early after peeing under the computer desk.

Sample movie (MP4/QuickTime 7 required, 64KB file): MotionDetection.mp4

No those aren’t mpeg encoding artefacts, those are my attempts to highlight the motion in the movie.

Source code: http://toxic-public.googlecode.com/svn/tags/BlogTag_20070927_729/Frameworks/ToxicMedia/Samples/SequenceGrabber (see MotionDetector subdirectory)

Have fun.