I’ve spent the last couple of months working on my B&O MP3 mod. I was hoping to have it finished in time for the MacMod competition but after a frantic week (and some sleepless nights) it became obvious that wasn’t going to happen – there was just too much to get done. At the competition deadline (August 31st 11:59 p.m. USA EST) the player looked like this:
Close, but no cigar (and no Mac Mini either). But despite this missed deadline things are generally going well with the project.
Most of my time has been spent working on the software interface for the player. I wanted this to be visually simple and take advantage of the B&O’s existing slide controls. I also wanted it to work with my iTunes library. I had thought this would be a simple task of writing an AppleScript program to control my music tracks through iTunes. It soon became apparent that AppleScript just wasn’t going to give me the interface control I was looking for. So, I thought I’d take a crack at Apple’s xCode development package; I’ve done a bit of HyperCard programming, how hard can Cocoa be? Well now I know; really, really hard.
It’s not that Cocoa or Objective-C (the programming language I’m using) are particularly complicated, it’s that when you’re teaching yourself something it’s very difficult to recognise the gaps in your knowledge; to know what it is that you don’t (and should) know. Thankfully there are a great number of resources, both on-line and in print, that provide detailed introductory tutorials, however even with these resources it wasn’t until two weeks ago that I realised I was missing a fundamental element in my understanding of Cocoa software development. This missing element had to do with providing outlets between objects so that specific instances of a class may be accessed (instead of simply including .h files and having access to just the class methods). This may not make any sense to you, or you may think it’s so obvious that I must be some kind of newbie idiot, but my point is that it’s only when you realise there is something missing that you are able to see this gap in your knowledge (and can then do something about it).
This becomes significant when trying to teaching yourself something from a knowledge source which is disparate and multi-vocal (such as the internet). When working from a single text it is relatively easy to map your knowledge against that text, any discrepancies between your understanding and the text become plainly evident. When working from dispersed sources this comparative process is not so easy, the sources themselves (as a collection) lack a meta-structure to define their extent and relevance. This meta-structure must be provided by the project/research being undertaken, hence gaps in understanding don’t reveal themselves as deviations from a given structure but as uncharted areas in a network of relations that is continually developing and mutating.
Of course even a singular text is never singular, it is always inescapably multi-vocal and it’s meta-structure is not fixed but a function of the project at hand; it is never the same for me as it is for you. So this issue of the unknown unknown is always present within research; there will always be stuff that you don’t know, and even scarier stuff that you don’t know you don’t know. I guess the trick is to try not to think of this unknown as a failure but instead as an intrinsic part of research. When I discovered what it was that I didn’t know about Cocoa I was very excited (yes, I’m a girlie swat). I need to remember that it is the absent presence of the unknown unknown that opens up a space for discoveries such as this and allows excitement to enter the research.