- 2009 (1)
- 2008 (5)
- ▼ 2007 (10)
I’m pretty happy with my current-model MacBook Pro 15”. I got the Santa Rosa based 2.2 GHz model via a very good education price deal (I work in a university), and it’s a great all round machine. Because I take lots of photographs, I have calibrated the MacBook Pro’s display as well as my 23” Cinema Display so that I get true colors when preparing photos for web or print. I used the Spyder2 Express from datacolor, which is a great little gadget. The idea is very simple: you use the supplied colorimeter to look at your monitor while an application displays swatches of known colors. The colorimeter reports the actual color appearing on the monitor, and the controlling application creates a table that records the difference between the RGB values in the swatches and the ones recorded by the colorimeter. This is known as a device color profile and the Mac can use its generic factory-shipped ones, or the more accurate ones you create for your own displays with the Spyder2 or similar devices, to calibrate your screens. Once you’ve done this calibration, you can be confident that the colors displayed on your monitor are as close as is technically possible to the colors the original creator of the image or graphic design intended.
So I ran the calibration process and used the new profile. It looked richer and crisper, and prints I made using Adorama and Apple’s printing service accessed via Aperture were true to the colors on my screen. Photographically, everything was perfect. However when using NetNewsWire, or looking at certain sites such as Facebook, I noticed that a range of greys would actually be displayed as pink (see first image). I re-ran the calibration process a few times but still got the same result. I wasn’t happy with this - it was annoying me, and I spend enough time looking at this screen for it to matter.
I searched a load of Mac sites using Google’s Mac-specific search, and didn’t find anything helpful. I then turned to Apple’s Discussions Forum for the MacBook Pro and found a couple of articles which narrowed the problem domain to people exactly in my situation: they’d got a new MacBook Pro with the LED backlight and calibrated it with a Spyder2 or similar device. It seemed that the problem was that the current Spyder2 software, version 2.3, was hard-coded to use a white point of D65 (equivalent to the color of light emitted by something heated to 6300° Kelvin, and for years regarded as the best technical definition of the actual color of daylight). From information in the discussions it was clear that version 2.2 of the software still had the white point hard-coded to whatever the display’s hardware regarded as white (Native white point) and this was preferable in this particular case to what Version 2.3 used to create the profile. Luckily Datacolor makes version 2.2 available on its web site, so I went there and fetched the older version. I chose to put the old version of the software in a folder called Applications in my home directory, instead of the main Applications directory.
I ran the old version of the app, and let it do its thing. When I looked at the display as managed by the new profile, it looked fine - the pinks had gone (see figure 2). Then I turned the Cinema Display back on, which had been off because, as my friend David says of a similar screen, you could light a cigarette using its output and a cheap lens at 50 feet. In fact it’s so bright that as the sole light source in our living room it will let you expose a decent shot of the room at f/22, ISO 400, in only two seconds. Spillage from this monster would have biased the calibration process. Cross checking with the Cinema - which was my reference screen - showed that while the greys were now pleasingly neutral, the whites on the MacBook Pro were now a faint but nauseous green. I tried to stick with this state of affairs for a day or so, but as I switched my attention between the Cinema and the MacBook Pro displays, it was even more jarring than the pinkish greys, and I changed the profile back to the original one.
I was stymied. The old version rendered the greys correctly, but produced unacceptable whites. The new version had crisp clean whites but pinkish greys. The Apple standard profile was too pale and too blue. Running manual calibration on the Apple profile but setting the gamma to 2.2 instead of the historic default of 1.8 helped with the paleness but didn’t help with the pinks. The male line of my family is genetically blessed in taking lush, healthy heads of hair to the grave, but I was at risk of being the first of our line to die bald as a result of my frustration. The only solution seemed to be to get hold of either upgraded software for the Spyder2 or get a better system such as the Eye One Display 2.
The answer came, as it often does, serendipitously. I was reading Macworld.com and came across Dan Frakes’s review of various brightness controller apps for recent Mac models. I had not really felt the need for extra control of brightness of the displays I use - I thought I was managing quite well with the native keyboard-based controls for the MacBook Pro and the Cinema Display’s Star Trek-like touch controls on its right-hand side. Nevertheless something impelled me to try Shades. I installed it, and then pulled its onscreen brightness slider down a little to dim the display slightly. The effect on colors was dramatic - the pinkish greys became the most neutral of shades possible. I nudged the brightness back up and the pink flush returned. I used the hardware control to dim the display and instead of the neutral greys I expected, I saw darker pinkish greys. Clearly Shades is doing something different to what the hardware backlight control is doing. I don’t yet have an explanation but I’m heartily glad that I have a solution.
The lesson here is: never stop reading, never stop experimenting. You can even make an analogy with biodiversity: we never know what we might need until we need it, and at present we’re eliminating our options as to sources of rare and interesting molecules every time we let a Western feedstuffs company wipe out a tract of forest or jungle. We’ll pay for that, and maybe sooner than we think. In the Mac world, it’s the small developers like Charcoal Design who are accidentally solving problems they probably don’t even know exist. It’s in every Mac user’s interest to cherish and support them.
- One great thing about Macs is that applications are just files (they’re actually folders (directories) pretending to be files, but usually that doesn’t matter) and you can put them anywhere and call them anything you like. This is another great feature of Mac OS X - you can put any app in this folder and it works just as if it were living in the main Applications folder, but it can’t affect any other user on your computer. It’s very useful for trying out new versions of programs (or in my case, older ones).
Frequent spreadsheeters are used to constructing formulae by pointing with the arrow keys. It's part of the spreadsheet conditioned reflex set to whack equals, arrow left, hit star, point left left, whack enter, to construct a typical "cost times quantity" cell formula. This has been braided into the finger muscles and the spinal cord of spreadsheet workers since VisiCalc, through Lotus, SuperCalc, Multiplan and Excel. Numbers retains the equals operator to introduce a formula (much more intuitive than Lotus's plus sign and less confusing than SuperCalc's complete lack of formula signifier) but forces you to mouse around the relevant cells to assemble your formula. It's a bit of a drag, honestly. I hope this becomes something the end user can change.
Secondly, Excel VBA macros are not preserved by a round trip from Excel into Numbers and back to Excel again. The entire VBA OLE stream within the file is just removed in any Excel file exported from Numbers. This is something to be aware of when collaborating with Office users who make any use of Excel macros.
That prompts the question “how can you have a serious spreadsheet that doesn’t have a macro language?” but honestly, I’m very far from convinced we really need one. I’ve seen countless examples of Excel sheets with macros that could be very easily replaced by a couple of ranges using some of the many hundreds of powerful Excel worksheet formulæ, if only the sheet’s constructor knew them. In part I blame Microsoft’s switch to online documentation for this ignorance of the true power of the app. I learned Excel by taking the thick, brown-and-white (Mac) or blue-and-white (Windows) perfect-bound Function Reference book home and reading it from cover to cover, so I got a complete picture of what sorts of functions were available and how to use them. It’s so much harder to get a good overview of the capabilities of the application by browsing the unattractive online help and reference. Excel’s calculation engine is optimized for ripping through huge arrays of formulæ like a shark is for swimming and catching prey. It does incredibly fast matrix operations. Asking it to sit around and wait while some large interpreted, procedural script runs is giving it an enormous handicap, and in most cases a totally unnecessary one.
Anyway, it barely matters now, as - like I’ve made much of here before - Microsoft can’t devote the necessary resources to bringing the VBA engine to Intel Macs. You can still write scripts in AppleScript that access and animate the Office VBA object model, but their code statements are horribly verbose and hard to parse compared to their (scarcely elegant) VBA equivalents. If you’re interested, April 2007’s MacTech published a supplement on converting Excel VBA to AppleScript. I suspect a lot of spreadsheet users will move to a more formula-based spreadsheeting model as time passes, and to me, that’s a good thing.
Maybe you've seen the latest in the Apple TV ads featuring John Hodgman and Justin Long (“Hello, I’m a Mac” “And I’m a PC”). Normally these are pertinent and witty, but the latest one isn’t up to the standard required when you’re trying to occupy the moral high ground. Hodgman (PC) lumbers on stage looking like Richard Griffiths in a brown suit, bloated and burdened by the weight of “useless” trial software, and says it “…really slows me down”. This perpetuates a meme you’ll hear repeated everywhere, even by IT support people who really should know better: that too much ‘stuff’ on your hard disk makes your machine run slower. There’s no real relation between how full your hard disk is and the speed of your computer. Software that’s installed just lies around on disk until you run it. When it’s not running, it can’t affect your system speed, whether that system runs Mac OS X, Windows or Linux.
The only things that might slow down your system without your wanting them to are pre-installed antivirus or firewall apps (Dell used to bundle McAfee products set up to run automatically) but as you shouldn’t run a Windows machine without at least some anti-virus software, and probably a firewall if you share your network with non-experts, I’d give that one a pass.
Oh, and while we're at it: Apple pre-installs trial versions of both its own office suite, iWork (can it be a suite when it has only two components?) and Microsoft’s Office. Microsoft Office won't even print until you purchase it. How useful is that for a suite that includes a word processor? And on the subject of disk space: the pre-installed iLife apps that are included in the price contain some fat boys themselves. iDVD tips the scales at around one and a half gigabytes with plenty of video templates under its belt, and iPhoto weighs in at half a gigabyte with all its templates.
I believe, with a lot of justification, that Macs are better in almost every area than Windows PCs. Apple’s been good about stressing the points where the Mac is better without recourse to misrepresentation or FUD. It’d be too bad if an overly zealous ad agency started to fling mud when its client isn’t exactly alabaster white.
I was recently talking with a friend who is thinking of replacing his beloved but aging eMac 700 with something modern, and was trying to help him work out what the smart buy for his usage would be. His current complaint was that he gets the spinning beachball in Safari an awful lot and the entire system seemed sluggish when he had several browser windows open. I got him to run Activity Monitor to examine whether Safari’s cache problems were contributing to the slowness. One of the things he mentioned that startled me was that iTunes on his machine was taking a steady 25% of the CPU time.
I was surprised because on my daily machine, I’ve never seen its usage vary much from around 10-11%. Then I compared my machine’s CPU (a 1.67 GHz G4) with his (a 700 MHz G4) and realized that the amount of work being done by both machines was similar, and because his CPU was about half as fast as mine, it was having to do twice as much work as mine in the same time to play back the MP3 file. iTunes doesn’t have the option to do the same work at the same rate over twice as long a time, of course, because then your MP3 music would play back at different speeds depending on how fast a processor iTunes was running on.
I was curious to know exactly what iTunes was doing with the CPU cycles it was consuming, so I opened Activity Monitor on my PowerBook while iTunes was running, and found the iTunes process in the list. I clicked Inspect to bring up the detailed view of the iTunes process, and then clicked Sample. What this does is ‘trace’ all the system calls made by an application while it’s running, so you can see exactly what it’s doing at any time. The output it produces is shown in the image (left). The more you know about Mac OS and Mac programming, the more it’ll mean to you, but it’s not hard to figure out the very basics of what an app is doing whatever your background.
I ran a few traces on iTunes as it was playing music, and I was surprised to see that in every sample there was just as much work being done in graphics calls as in the actual reading, decoding and playing of music. You can see some of the graphics related work highlighted in the trace sample. Everyone who uses iTunes will have noticed the smart-looking LCD-style display at top and center, which mimics the screen of a G3 iPod and shows the current song information. There’s a progress bar showing the playing position of the current song, and if the song name is wider than the display, the text of the name scrolls right to left. It seems animating this display is quite expensive in terms of CPU power.
In order to help my friend with the eMac, I mused, it would be nice if we could do without the graphical work that’s draining his processor. The easiest way to do this is to run iTunes without a window. This won’t be intuitive to current or recent Windows users (and sadly, the facility isn’t available to Windows iTunes users), but the vast majority of Mac apps can manage quite nicely without any open windows. On Windows, however, when you close all an application’s windows, the application quits. Back on the Mac, though, you can give iTunes a list of tunes to play, press the Play button and then close the iTunes window, and iTunes will happily play through your list of music whilst remaining ‘invisible’.
So I started iTunes playing and closed its window, and checked Activity Monitor to see what it was now doing. Sure enough, the graphics calls disappeared from the Sample trace, and the CPU utilization dropped by about half, so that on my PowerBook it went from 11% CPU to around 3.8%. Hiding the application produced about the same result, and minimizing it to the Dock used slightly more CPU, at 4.4%. I was mildly surprised by the last result, because Dock icons are ‘live’ to some degree, and I’d expected iTunes to still try to draw a miniature version of the LCD display. I reasoned that if the icon is so small you can’t see the display, iTunes will not try to draw anything too complex.
I repeated the test on my 1.6 GHz Core Duo Mac Mini, which has the equivalent of two 1.66 GHz CPUs, and the total CPU load was 3.9% when iTunes’ window was visible, but only went down to 3.0% when it was closed or hidden. The comparison between G4 machines is sort of meaningful, but comparing across machine and processor architectures, and instruction sets isn’t very useful; all that I took from the last test was that there’s minimal benefit in hiding iTunes on an Intel Mac Mini.
I’m glad to say that by hiding iTunes, my friend reduced the CPU load due to iTunes from 25% to 8%. So, if you have an older Mac and you’re seeing it begin to struggle while playing music, just hide iTunes and grab some cycles back.
According to Barrington-Coupe, he only used parts of the other artists' recordings to smooth over bad takes. However, iTunes, or rather the Gracenote service iTunes uses, identifies CDs by a complex hash of attributes including the ID String embedded by the presser, as well as track numbers and durations. For obvious bandwidth reasons, it doesn't sample the actual sound on the recordings so there's no way it could have 'heard' and identified a different pianist from the patching pieces Barrington-Coupe says he dropped in. Rather, the fact that iTunes identified the disc as being of the same works implies that the CD master of the Hatto disc would have to be exactly the same as the 'copied' disc, bit for bit and note for note. Yes, there are sometimes collisions - I remember once being informed by WinAmp that a RedHat Linux CD I'd put in my machine was in fact a compilation of funk anthems by the futuristic Parliament - but the chances of such a collision of attributes happening for two discs of the same works is one in tens of millions.
This makes Barrington-Coupe's confession still unsatisfactory. Gramophone is skeptical:
The question remains as to how much of this confession we should actually believe. It is in some ways a humane, romantic story. However, newspaper investigations following the first Hatto revelations have uncovered shady dealing from Barrington-Coupe’s past. He received a prison sentence in 1966 for failure to pay purchase tax. Whether this throws doubt on his confession now, made only after our revelations and in the light of the fact that he continued to release “Hatto” recordings after his wife’s death, is open to debate.
That said, you can't let your life be run by random events and dropping everything to work on whatever the customer who shouts the loudest wants. You need some sort of system, and I've found the system popularized by David Allen, which he calls by the arcane, obscure name of Getting Things Done, works best for me. It's a simple system. I can try to summarize it by saying that it's about collecting all the things you have to do in your life into a single system, then classifying them into what you're going to do, how you'll do it and when you're going to do it. There's a fair bit more to it than a single sentence, but that should give you the gist. It's also a system that is very usefully managed using computerized methods. Computers know what date and time it is and are great at reminding you about things that are due. They're also great at sorting and categorizing lists. Those two functions are necessary tools for organizing a task list, but the precise way in which the functions are presented to the user can make a huge difference between a system that works for you and one that gets ignored.
I do all my information management on a Macintosh, and I've tried a good selection of Mac applications that work in the GTD way. For the longest time, this meant what I think was the very first "application" in that field, Ethan J. A. Schoonover's Kinkless GTD (kGTD). I've put "application" in inverted commas because kGTD is actually a suite of AppleScript scripts that act on OmniOutliner Pro. I don't want to belittle Ethan's mammoth effort in creating this system; as anyone who's tried to develop in AppleScript knows, doing anything significant is hard work. I just want to be clear that in order to benefit from Ethan's hard work, you need to own OmniOutliner Pro too. A large number of Mac customers received OmniOutliner (standard) with their machines - I know I did when I bought an iMac G5 and a PowerBook G4. kGTD needs the Pro version and at present the upgrade cost is $29.95. While I appreciate the immense effort Ethan put into this system, he's the first to admit it's not perfect. I had a big problem with it when out of the blue, it decided to blow away all my tasks during a synch with iCal. After that I disabled the iCal integration, which halved its usefulness for me. Luckily just about then, Ethan and OmniGroup announced that they were going to work together to produce a proper, Cocoa GTD application called OmniFocus. However that was a while ago, and it's another while before it's available to buy and use.
In the meantime I looked about for a replacement. I tried ActionTastic, Midnight Inbox, and Thinking Rock. I didn't get on with any of them well enough to adopt them as a permanent replacement for kGTD. Then Alan Fleming mentioned Ghost Action to me. When I first looked at it, I was convinced that ActionTastic had been renamed, because the UI of the two products is very similar indeed. However the products are in fact different, not least because Ghost Action is being developed in a very interesting way - it's using the RubyCocoa Framework, and its code is written in Ruby, a modern, flexible and object-oriented scripting language. Ruby is very powerful at doing Perl-like things but using this framework, it's very clear that it's also able to produce 'proper' OS X applications with equal facility. Ghost Action maintains three views of your actions: Contexts, Projects and a full list of all your tasks under Actions. This fits with Allen's tenet of 'planning in projects, acting in contexts'. It also has seemingly flawless sync with iCal, which seems to have been a stumbling block for other apps I tried. The sync is two way, and creates a calendar for each context in iCal, prefixed with @ - so that your 'Calls' context becomes a calendar called @Calls. It also appends the name of the project where each action belongs to the name of the action, for clarity.
The developer, Jacob Wallström, is accessible and responsive - I updated it to a new version one morning and found a crasher bug immediately, because I like to use all applications that require data entry using only the keyboard, and this bug was to do with tabbing into and out of fields. I reported this immediately and by the afternoon, Jacob had pushed out another update fixing the bug. He also replied to my bug report personally and also took on board a couple of usability suggestions I'd made.
If you're looking for a quick and simple way to implement the GTD approach in software on your Mac, why not give Ghost Action an outing? There's a free 14-day trial period, after which purchase is $19.95 or local equivalent.
You use iDisk through the Finder, which, in the background initiates a WebDAV connection to Apple’s servers. When the .Mac weather’s bad, this connection can be too slow or lossy, leading to spinning beach-balls and a halting, stuttering Finder. The way I cope with this is to use Transmit which can us WebDAV as well as FTP to connect to remote file systems. Transmit is blindingly fast at everything it does and slices through the bad weather in a way that the Finder doesn’t seem to be able to manage.
You can do various useful things with the 1GB storage available on iDisk, such as putting files on it for others to use. Mac users can get to the files by mounting your iDisk, and users of other platforms can see and download your files using a Web interface that you can quickly and easily put in front of your disk. You can also give other people permission to put files there or delete them - if they use a Mac. If you want to share files with Windows users and have them copy or remove files from your iDisk, there’s no official solution. There is a Windows client for iDisk, but firstly, it’s only available if you have a .Mac subscription, and secondly it can’t be used unless you have a .Mac account. It can’t be used by the average Windows user to manage files on your iDisk.
That was the very situation I was in the other day, when working with a colleague in the UK. Fortunately I found a generic WebDAV client that works with iDisk. It’s called DAVExplorer and the best thing is it’s a Java application, so it works on any platform that has a Java Virtual Machine - including Windows and Linux.
There’s a trick to getting to somebody’s Public folder from a DAV client. The person who’s using your iDisk will need your .Mac user name and the password that you assigned when you set up read-write access to iDisk (set in the .Mac preference pane in System Preferences). Anyone using DAVExplorer should connect to the path
that is, you have to tack
-Public onto the end of the iDisk URL. If they do that correctly, then .Mac will present them with a standard login dialog. The username they should use is
public and the password is the one you assigned earlier. That done, they will be able to add and remove files from your iDisk without having any kind of .Mac account.