Blog::new

I like Twitter, find it practical for many a thing, and use it myself. At the MIDEM 2010 it really was the lifeline of the event. But in between the ‘RT’, ‘@username’, and ‘#keyword’, there’s even less space to express anything really useful. Oh, and let’s not forget URL shorteners which add to the crypticness of the resulting message.

So, what I’d like : 512 chars (half a kilobyte, c’mon) for the message, and an metadata part where you’d add keywords and URLs. I suppose usernames can stay in the message since they wouldn’t make much sense outside of it, but keywords I doubt it. Ideally, we could mark them as keywords while typing, but the marking would be removed in the final message and the keyword would be added in the metadata. e.g. type “this is a message with a #keyword”, results in “this is a message with a keyword” along with a metadata block containing “keyword” as a, well, keyword.

Just for that I think I’ll go check what Google Buzz looks like.

A quick recap : that section enforces the use of Objective C, C or C++ for iPhone app coding. First reaction is obviously hostile (quite legitimately, IMHO).

More interesting, however, are the following short exchange between an iPhone developer and Steve Jobs himself, and John Gruber’s rethinking on the subject. It boils down to Apple not liking layers over their SDK because they feel they hinder software quality.

My personal experience very much agrees with this. Unless you’re under exceptional circumstances or requirements, you generally don’t want to add some cross-platform layer between you and the native development framework. An exception is if the framework is really too low level and calls for a higher-level one, but if Objective C was higher level, it would be a scripting language. An intermediate layer generally means that it will make simple things easier, but will make everything else (anything not directly supported by the layer, and debugging) a lot harder (especially debugging). It also means you depend on the vendor of that layer to support the last available features of the platform it wraps. And if it’s a cross-platform one, you’ll only get the lowest common denominator.

That said, while I understand Apple’s effort to maintain a globally high level of quality on the App store (they do advertise quite a lot about it), I really don’t think actively blocking these other frameworks is a reasonable move. First, it looks paranoid and bitchy. Apple can be that, more often than not, so adding more to that trait doesn’t help. But more importantly, these frameworks still may serve a useful purpose. In many cases, an application can be just “good enough”. Even if that’s hardly Apple’s style, an ugly, poorly integrated but useful and working application is better than none at all.

Another possible reason I see for this is the need to be able to easily audit applications, especially given the new multitasking features of iPhone OS 4, which have some aftertaste of cooperative multitasking.

But ultimately, I think Apple should do what Google did with Android : an official App store where what you buy is Apple-certified, and allow alternative App stores where you’re on your own. That said, I don’t know how the average user would handle that.

While I’m at it, Apple should also do the same for Mac : create an official Mac OS X app store, along with the current means of software distribution (i.e. downloads from various http sites). Think Linux distribution repository.

Edit Apr. 17th 2010 : An interesting alternative view on the topic from Steve Cheney is that by enforcing the use of XCode, Apple ensures its independence of the hardware. Indeed the transition from PowerPC to Intel went remarkably smoothly, and the fact that Apple provides the main development toolchain for OS X is a big reason why.

Edit Apr. 21st 2010 : Right now the download pages at apple.com are no longer being updated. And from the comments on this tuaw post, it seems I’m not the only one thinking that a Mac App Store is in preparation .

Edit Apr. 26th 2010 : well, it seems that no, there won’t be a Mac App Store. Can’t be clearer than that.

Following up on this post I had written about the iPhone becoming the ideal universal remote, I’ve just come across this other post about the iPad’s even bigger potential as a remote control.

Although I believe Android’s openness will make it more versatile than the iPhone platform, I’m quite curious to see where the iPad will take it.

Aperture 3 is a huge breath of fresh air for me, opening up photo retouching to so many new possibilities while doing it faster.

Pretty much all the requested and hoped-for features are there (first of foremost, brushes, and curves), so I won’t get into that. Handling of the metadata is way better, and the idea of showing it like on the camera’s LCD screen is a very nice touch, and makes it much easier to read it a glance (in particular, I just love the display of the auto-focus points).

At first I was surprised that the “new features” page doesn’t mention anything about performance, beyond the fact that it’s now 64 bits. I was expecting stuff about some of Snow Leopard’s new technologies (Grand Central in particular), for which Aperture would have been a prime candidate, but no. However, after using it for several hours it is much faster and more responsive – the loupe in particular is almost lag-free. Loading images in is still a bit slow, but then again I’m dealing with 20-25Mb raw files here.

There’s no improvement on b&w conversion (still the same monochrome mixer) beyond the fact that it’s now “brushable” (b&w/color mixes here I come – back), but the presets are a step toward film/paper emulation. Surprisingly there are already two “black and white” sets of presets (may be a buglet of the trial version). The first one contains two “old film 1″ and “old film 2″ presets, neither of which are particularly well done, but that’s a clear indication of things to come. What’s more, the Aperture 3 plugins page also mentions presets (though marked as “coming soon” for now).

The disappointment comes with the Web export features. Be it to flickr, facebook or iWeb (that is, importing Aperture images on a photo gallery page from iWeb), there is almost no flexibility over the process. In the case of flickr, which gives you a lot of freedom over the resolution of the images you upload, Aperture gives only 3 settings without any technical indication on what they are. More annoying, no control over how the metadata of the Aperture image is reflected in the exported image, and the default behavior (using the Version Name as caption, ignore all the rest) is silly. Likewise, no control on the flickr keywords either.

This is quite annoying because Aperture is clearly pitched as iPhoto Pro. But with these features (flickr/facebook export), it’s still as basic as iPhoto, and certainly not “pro”. Still, Apple is clearly not letting Adobe being the sole player in that area – give the state of their relationship, that’s hardly surprising.

Sooo, for once I’m going to blog about current news

Like almost every geek out there, I’ve been rather disappointed by the iPad. However, as many others have said, the iPhone had already revolutionized the way we think of computer user interface. It was obvious that it couldn’t have been a MacOS tablet. They had to adapt MacOS X to a tablet with multi-touch interface, and that is… iPhone OS.

This comment from a reddit thread sums it up quite nicely : “Why isn’t it a COMPUTER? We wanted a fucking tablet computer, not an oversized iphone – Because they’re not selling to you”. Yeah, this isn’t a geek tool. Although I have a feeling that, just like with the iPhone, many geeks will want one too.

Now it seems one of the main gripes against it is the lack of Flash. I really don’t understand why. As a chat on the topic with other friends proved to me this morning, Flash has two main uses nowadays : video, and games. Videos are on iTunes. YouTube is a native app. Other video sites already have iPhone (or more generically “mobile”) versions, like Dailymotion. And as for games… well that’s the first 3rd-party product which were shown during the presentation. And it would make sense that those people writing those fun little Flash games would be more than happy to sell them on the App Store.

Regarding Flash being used as a UI on website, now how are you going to translate that to the iPad’s UI ? The whole thing is designed to be used with your fingers as pointing devices, scrolling, etc… and by visiting a web site, you’d find yourself stuck with a UI made for a mouse&keyboard interface. How convenient.

And yes, of course, there’s the obvious reason that Apple (Jobs) is a control freak and doesn’t want anyone else to interfere with the Experience they provide to the user, that Flash is a resource hog, etc… I personally won’t miss it.

What I do miss, though, is multitasking, and it would have been really cool to have a video camera in there. And for the whole thing to be a tad more open regarding app installation, but that calls for the same answer as above : Apple’s not selling this to me. I might get one eventually (will wait for v2), but I won’t use it as a computer.

Edit : Two posts which I found seeing beyond the feature list check :
This one by Fraser Speirs (btw, thanks for your FlickrExport Aperture plugin ), and the other by John Gruber.

So the MIDEM 2010 is closing today. I attended as a press photographer, mostly did concerts (some great stuff), but also a couple of press conferences. Anyway :

• the industry is definitely moving towards other non-repressive solutions and alternative models to keep the business afloat. To quote Ted Cohen : “We’re decisively moving from music as a product to music as a service … this isn’t my opinion, this is fact.”. Good for them. As a sign of this, two or three (not sure) Rock Band booths, plus many talks and deals with video games companies. Spotify and Deezer were also very present.
• Politicians however are still lagging behind, still stuck in the same way only beginning to look at the possibilities of legal offers as a way to effectively fight against illegal sharing. The press conference I attended on the matter was rather pathetic in its lack of vision. Only the SPEDIDAM (warning, annoying website with auto-maximize windows and Flash all over, yuck), french organisation of authors to collect royalties like the SACEM, has a refreshingly sane view on the matter.
• The music industry is Apple’s turf. iPhones and macbooks (unibodies) were outnumbering blackberries and PCs 5 to 1 (rough estimation). To give an idea : the MIDEM iPhone app was downloaded more than 4000 times. There were 7000 attendees at the MIDEM this year.
• The conference relied heavily on Twitter as a “life line” for news, buzz, and communication between attendees. In that regard Twitter really has become a de facto instant communication platform standard which events can very easily get working : just agree on a keyword to use (#midem in that case) and off you go.
• Videogames (Rock Band, Guitar Hero…) had quite a bit of presence. According to this blog post from Le Monde journalists (in French, sorry), listening sessions organised by videogame producers to look for music to go with their games had a lot of success

That’s all for now.

(edit Feb 12th : added bit about videogames)

Now that basic (very basic) editing, recording and playback are in, I can show a quick demo of EdenX (that OS X would-be Rosegarden clone I’ve been working on). At this stage there’s really not much point in demonstrating it, given how little it does and how bad it looks (I’ve been throwing the UI together as it went). But it’s ripe for a Linux/Qt/C++ – OSX/Cocoa/ObjectiveC comparison, which is the underlining topic of this post. As such, OS X coders can stop reading. Linux coders, you might find the following interesting.

In the screencast I create two tracks, start two MIDI sources – one being MidiKeys, the other being a quickly hacked MIDI Sources and events generator (MSEG) which I wrote because I needed to test recording from several sources. Once these two programs are running, I create two additional sources from the MSEG, set one track to record from MidiKeys and the other from one of the created sources. I then start recording, send some events from the MSEG and then MidiKeys, stop recording, and do a play back at 120 bpm and then 250 bpm. Finally I save and reload the document.

In case your browser doesn’t support the video tag, you can download the mp4 here.

(nb: yes, the audio’s only on one side, thanks to a crude mini-jack cable )

Now keep in mind that even though I’ve been working on this for more than a year now, on average I’ve probably been spending about a couple of hours per week on it. As you can see by looking at the code, there’s really not much in it – around 1kloc. Although I’m now linking to two (well, one and a half – PYMIDI and the MIDI message parsing classes of SnoizeMIDI) Open Source MIDI frameworks which do help quite a bit.

But there are a few features which I’d like to highlight :

First, the track editor. As you can see from the demo, it can add, delete and edit events (yes, these buttons work, even though I don’t exercise them ). It also automatically updates when a new track is selected in the track list, and when new events are recorded. And yet, the whole code for this is roughly 30 lines long. Everything else is defined in the Interface Builder.

Second, there’s no code to define the document’s data structure, nor is there any for document persistence (save/load). It’s all done through Core Data : .

Also, here’s an example of how you fetch document elements. The :recordingTracks method returns all tracks which have a selected input source and ‘recording’ toggled on.

More generally, thanks to Key-Value Coding and Key-Value Observing, there’s practically no code anywhere to keep a widget up to date with the data it’s showing. For instance, the bpm slider is simply set to “point to” the “tempo” attribute of the document’s composition with the Interface Builder, and that’s it. Totally mundane for any seasoned OSX developer, outlandish for me as a former Linux coder.

Also, there’s no code for memory management because I’ve enabled Garbage Collection.

As a conclusion, I started EdenX as much to have a bit of fun with Cocoa (a feeling I had long lost with Linux) as to prove a point, which is that Cocoa is substantially better as a development environment than anything there is on Linux, even KDE/Qt. And there it is, there’s simply no way anyone could achieve this tiny bit of code in any reasonable amount of time on Linux, with the same amount of features, under the same constraints (i.e. a few hours per week at most). I don’t even want to think at how much code would be involved, plus the MIDI configuration hassle.

It is often said the grass always looks greener on the other side of the fence. It looked like it when I was on the Linux side. Well, having roamed on the OSX/Cocoa/Objective C side for a while now, I can tell it wasn’t an impression : the grass is indeed a whole fucking lot greener.

Another tweet, another milestone : edenx recorded its first notes on sept. 24th. Notes sent by a quickly hacked MIDI client which sole purpose is to create virtual MIDI sources at will, and send NoteOn/NoteOff events on them. This was done thanks to Pete Yandell’s PYMIDI framework with the messages parsing classes from Kurt Revis’ SnoizeMIDI added in, which saved me a lot of time.

Even creating the MIDI source client was a breeze. I haven’t yet updated the svn repository, I need to fix a small array controller issue first.

All my pet peeves against Linux rolled into one. From Google and Adobe engineers, no less. And of course, most of the replies are “yes but we’re free, we have choice, etc…”. *sigh*.

Two weeks ago I did my first concert with my new 5D markII (Lenny Kravitz, no less). I’m quite happy with the results. In fact I’ve never, ever brought so many good shots from a concert. By “good” I mean “exploitable” : low noise, correct exposition and focus. A quick statistical check on a few of my previous concerts yields an average ratio of 30% of keepers/taken. In this concert, the ratio was 54%.

I’ll spare the praise on its high-ISO performance. Everything you’ve already read is true, yes you can shoot at 3200 and get something exploitable. Noise becomes noticeable at 800, under that it’s irrelevant. But the other huge improvement compared to the 40D is a working auto-ISO mode. This allowed me to take shots at 100 ISO. In concert. I’d never have thought that possible, but I have a bunch of perfectly sharp shots taken at well below 800, which is usually the lowest setting I use in concert (sometimes 400 when there’s really a lot of light). The other good part of this mode is that, well, it varies ISO. Which means I have both noiseless, clear shots and fairly grainy ones when it kicked into 3200, and this lets me vary the mood at post processing. From

to

In conclusion : can’t wait for the next concert