Last week, I posted a note on the RapidWeaver forums saying that I was thinking about making RapidAlbum open source. This is primarily because I don’t have a lot of time to maintain it at the moment and wondered if making it open source might not be a better way to tackle the problem. I write software for a living and only have so much time in the day to design cool stuff. And, more importantly, I only have so much space in my head to hold designs at any one time.
RapidAlbum is a reasonably large RapidWeaver plug-in so it takes a bit of time to come up to speed each time I step back into it.
Unfortunately, I haven’t had any real interest in RapidAlbum as an open source project. This leaves me in somewhat of a dilemma. On one hand, folks are still using it and expecting me to support it (at least a bit). On the other hand, the code is getting a bit stale and needs to be updated to the latest RapidWeaver 4.X APIs at the very least (as it still uses the old RapidWeaver 3.X APIs).
If you’re interested in RapidAlbum as an open source project, let me know. You can drop me a note via the contact page.
A few folks have dropped me email to ask about what I’m planning for RapidAlbum 2.0. As I’m still working thru’ some of the basic details, I’m a bit loathe to commit to what’s actually going to be in there but it does look (at the moment) as if it’ll be a ground-up rewrite. The basic code grew a bit organically during the alpha and beta phases of the 1.0 release and I really want to rewrite a lot of the core so that it’s more flexible (and maintainable).
The good news is that I’ve started on it. A lot of the projects that I work on for myself seem to need the same things over and over again. For example, MetaSync and RapidAlbum both need fairly extensive image metadata support and, until now, they’ve gone about that in a fairly separate way (MetaSync is Applescript Studio and RapidAlbum is obviously in cocoa).
In order to reuse as much as possible, I’ve started to strip out a lot of my existing code into general cocoa frameworks so that I can leverage them in lots of different projects. I should have done this a while ago but it’s not always easy to see the wood from the trees. This is what I’m busy working on right now.
I now have a standard metadata framework that will read image metadata from iPhoto, Aperture, MediaPro, Expression Media and the Finder into a common object structure. The goal here is to allow RapidAlbum to build smart web albums (i.e. it can interrogate iPhoto for all the photos in the “Santa Cruz” album) and to allow the next version of MetaSync (which I think will be called “Metal”) to synchronize between applications.
I’m hoping that once I have the basic support for other features (I need a general Inspector framework too), actually rewriting RapidAlbum will go really quickly.
We’ll see…
Due to a variety of pressures, I haven’t had a lot of time for Cocoa programming in the past year. That means that I haven’t been able to really get to RapidAlbum to start work properly on a 2.0 release or really begin on rewriting MetaSync.
I’m hoping that will change over the next few months. I’ve started work on the objects that’ll form the basis of the new version of MetaSync and RapidAlbum. The hope is to share almost all the code that handle metadata for images, along with a bunch of the support code.
I’ll post more as I work on things but I’m pretty excited about some of the features that look possible for MetaSync in particular.
I’m still not really browsing the RapidWeaver forums so if you have technical support questions for anything I’ve written, please use the contact form to get hold of me and I’ll try to take a look. It sometimes takes a few days to get to my inbound support mailbox but I usually do get there.
Cheers!
I’ve had a few questions about MetaSync over the past few months. As folks start to use Microsoft Expression Media 2, they often find themselves looking for the same tools that were available for iView MediaPro.
If you have Expression Media 2 installed, you’ll find that it actually ends up as a target for MediaPro Applescripts if MediaPro isn’t running (it is possible to have both installed at the same time, as I do). This is somewhat useful as it means, with care, you can use the same tools with both MediaPro and Expression Media 2.
However, the MetaSync 1.5.3 release had a gotcha that meant that it wouldn’t sync ratings across between catalogs. This was because of some old code that tried to check for MediaPro 2.X gotchas. I’ve removed all this code (as it’s prehistoric and if you’re running MediaPro these days, it’s not unreasonable to expect that you’re running MediaPro 3).
The end result is that I’ve cut MetaSync 1.5.4 – if you’re using Expression Media 2, you should find that this’ll work for you.
Cheers!
Although the main core of my workflow has drifted back to MediaPro, I still tinker with Aperture and Lightroom. I’ve stopped importing my DNG files into them but, somewhat perversely, I do still import my finished derivative files. This lets me play with things like slideshows and book generation without worrying about the conversion issues for my DNG files (in the case of Aperture).
As Apple release Aperture 2.0 this morning, I thought I’d download the trial version and play with it. There was a new feature (out of the 100 they list) that brought a smile to my face:
Reconnect override
Aperture 2 lets you “force-reconnect†images in the Managed Referenced Files window. Reconnecting to master images on a different drive is normally restricted to files that match in name, size, or date. If for any reason these attributes change in a way that makes normal reconnection impossible, you can hold down the Option key to force Aperture to reconnect to your masters.
Woo! This fixes a particularly stoopid gotcha in Aperture 1.5 – if you import images as referenced masters and then modify the metadata in the referenced master (say, using MediaPro to sync back a change), Aperture refuses to re-connect to the modified file. This is particularly frustrating and rendered Aperture useless for maintaining a shadow library of images that had externally managed files. At least now, I can force Aperture to reconnect against it’s better judgement.
Another new feature is long overdue too.
Duplicate detection on import
Click the new “Do not import duplicates†checkbox in the Import window, and Aperture suppresses the import of images already in the library.
That’s right. Aperture finally will do duplicate checking. Even better, the duplicate option shows up in the Import Automator action. I’m sure neither of these additions will get much press as they’re not that sexy but they really make a difference to the usability of Aperture. The eye candy is nice (and the simplified interface is an improvement) but it’s the small stuff like this that matters.
So a big “thank you!” to the Aperture development team for these additions.
I’ve had quite a few folks ask me recently about MetaSync. I suspect some of this is driven by the release of Office 2008 and the inclusion of Expression Media in the full package.
Funnily enough, I’ve been tinkering with MetaSync again after a long absence. Towards the end of 2007, I found myself growing dissatisfied with both Aperture and Lightroom in my current image workflow. There’s nothing that wrong with them per se, but I still use ACR in Photoshop CS3 for the bulk of my raw conversions. I did try using Lightroom for a while but I found it got really clunky when some images were offline. For big catalogs, it’s still really not an effective DAM tool at all.
The end result was that I found myself creeping back to iView MediaPro 3.1.3 – it’s not sexy but it doesn’t get in the way of my workflow, gracefully deals with offline media and is DNG-aware enough not to annoy me. It’s the least bad option, if you want to damn it with faint praise.
But of course, if I go back to MediaPro, I need to dust off my old workflow tools. One of the additions to Leopard was a scripting bridge to allow Applescript events to be generated simply from within Cocoa applications. This is an absolute plus for a tool like MetaSync, which relies on a lot of scripting to extract the metadata from MediaPro. MetaSync is currently an Applescript Studio application – adding more features than it currently has means that I either have to write a lot more Applescript (ugh) or write the new features in Cocoa and instantiate the whole thing from Applescript (bleah).
In Leopard, I get to re-write the whole thing in Cocoa. This is a Good Thing. My plan is to start working on MetaSync again fairly soon. Is there interest in making a version work with Expression Media? I can add this if there’s firm interest but I’m not going to write it on spec – I don’t use Expression Media yet (there’s nothing it does that I need).
One application that’s definitely missing from the plethora available for Mac OS X is a small, compact bug tracking tool for small software developers. I’ve used a variety of systems over the years but haven’t ever really been happy with them for personal use. I don’t want a web interface, multi-user options or integration with source control. All I want is a nice, clean database that allows me to keep track of the various problems and feature requests that users have reported. No mess, no fuss.
Because of this, I’ve been tinkering around with Bento over the past few weeks. And, with a little bit of adaptation, it looks like it might be ideal for small-scale bug tracking.
Here’s a list of active bugs and feature requests for RapidAlbum:
And here’s a detailed entry:
The theme that I’m using here is non-standard. The current selection of Bento themes is pretty horrible – it’s geared towards the sort of folks who think that Comic Sans is “cute”. However, if you open the Bento application package, it’s pretty straightforward (if you’re comfortable with a plist editor) to add a new theme that uses muted colors and a reasonable font. This limits the amount of eye bleeding that the current selection of Bento themes induces (what were they thinking?).
Bento also appears to be scriptable altho’ I haven’t started tinkering with that yet (an Automator action for parsing email messages and creating a new bug record would be ideal).
All told, it took under an hour of tweaking and configuring to get Bento set up for my bug tracking needs (and most of that was theme tweaking). That’s not bad at all.
I’ve just posted the latest minor release of RapidAlbum for download. You can pick up a copy here.
This version mainly fixes some annoying niggles and nits that users have reported. The big change is that RapidAlbum now creates empty metadata fields for all of the default IPTC and EXIF tokens if they’re not present in the image file. This means that you can edit and display information for images even if it’s not present in the original metadata – useful if you’ve got an album full of odd images.
Enjoy!
I’ve finally released a full version of RapidAlbum. The 1.0.2 release is available to download right now!
I’ll post more over the next few days about some of the changes in the final version of RapidAlbum. It’s seen some pretty large changes since the initial versions but it’s still fairly close to the original vision that I had for the plugin; a tool for building large photo websites with the minimum of extra overhead.
My thanks to all of the folks who tested and gave me feedback on RapidAlbum. I’ve still got loads of suggestions to build into RapidAlbum 2.0!
It’s been a bit over a month since I shipped the last build of RapidAlbum. Since then, we’ve had Leopard released and a couple of builds of RapidWeaver to fix various weird Leopard-related problems. Things seem to have settled down again.
I’ve cut RapidAlbum over to an XCode 3.0 project. Things went relatively smoothly but I did discover some weird translation problems when moving the old NIBs across to Interface Builder 3.0. Because of that, I’ve decided to cut a private release of RapidAlbum and ask for volunteers to test it before I release it en-masse.
It’s been tested on Tiger and Leopard, seems to be stable and fixes pretty much all the bugs that folks have reported to me (the most serious of which are related to the more complicated templates not working from within Blocks and custom file locations).
If you’re interested in testing RapidAlbum for me, send me some email via the contact page and I’ll point you at the disk image…
Cheers!