EdenX - a quick demo

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.