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.

8 thoughts on “EdenX – a quick demo”

  1. Honestly, calm down a bit! It’s been quite a long time for this still to be a personal war with Linux.

    Interesting technically, and I’d very much like to read more of this kind of thing (how you get on with the various bits of surrounding infrastructure for edenx). I could really do without the polemic though: it’s great that you know how to do better now, but we both know that the primary reason Rosegarden is a clumsy mess is because it was clumsily written. By us.


  2. I’m quite calm, but you’re right, the tone is more polemic that it should.

    That said, I strongly disagree with your point that Rosegarden was clumsily written. Yes we did our share of design mistakes, however we have no responsibility in the horrific mess that sound on Linux is, for example. Nor do we in the fact that advanced features like listeners or document persistence which are part of modern frameworks are unlikely to ever be available on Linux, for lack of standardization around a common development framework (among other things).

    No amount of rewrite or redesign will ever make Rosegarden as simple as it would be on OS X, simply because its environment prevents that.

  3. I deliberately said clumsily written, rather than clumsily designed. There were a lot of things we could have solved more elegantly, to end up with a more compact and easier to follow mess of code that worked around platform and toolkit limitations more cleanly.

    For example, in the new qt4 codebase we have a much more tidy means for organising menu actions and the like than the old kdexml + masses-of-boilerplate-code method; we could have done that before (there’s nothing specific to qt4 about it and it’s not that much code), we just didn’t think of it.

    I don’t deny that you may be using facilities now that didn’t exist for us then, and in many cases perhaps don’t exist for Linux developers at all now; I suppose all I’m saying is that by buying in to the idea of a non-vendor-supported platform (as Linux developers do) we can hardly blame the platform for the fact that they don’t exist, because we make the platform. Your switch of platforms was correct, not because there is anything intrinsically blameworthy about Linux as software but because you realised that you in fact didn’t buy in to the ideal of a community that builds it all itself.


  4. Actually your example of menu actions is quite telling of the leap between Linux/Qt and OSX/Cocoa. On Cocoa, you just drag another menu item to the menu bar and connect it to the relevant action (ctrl-click on the menu item, drag to the object containing the action), all from the Interface Builder. Low-level UI stuff is simply out of the way.

    Of course I am using facilities that we didn’t have, that Linux will never have, actually. I have a soundfont-capable audio and MIDI sequencer, with a default soundfont, already there in the system. I have a framework which lets me graphically design the data structures of my document and takes care of the saving and loading. That’s the equivalent of thousands of lines of RG code.

    I don’t blame Linux for its shortcomings, I’m just stating them, and they are indeed inherent to its very nature. When I started this, you were puzzled that I didn’t go for a straight port since it was also doable, and that was the sane choice for you. Though I told you that Cocoa was much more powerful as a reason to justify my choice, it’s more convincing if I actually provide an example of what is possible.

  5. Well, the question of which development choice was “better” obviously depends on your criteria; it’s not the same thing as the question of which development framework is better.

    It’s surely hard to dispute that a straight port would have been an easier and quicker (if relatively boring) way to get a full-featured version of Rosegarden running on OS/X — and from my dull, businesslike point of view that seems like a sane thing to want, even if I have no particular use for it myself.

    (After all, the current SVN version already builds and runs on OS/X — http://www.all-day-breakfast.com/m/thorn-osx-blah.png — without anyone having ever lifted a finger to port it. It lacks sound drivers, but you could have hooked those up by now.)

    I accept that there are perfectly valid (to you) reasons to rewrite rather than port, such as that you think it’s more fun and that the result will be a better program. I’m not all that excited by those reasons myself: I don’t do OS/X development for fun, and an OS/X-only version would not seem a better program to me.


    1. Yes, we’ve already had this discussion. It’s a shame though, I’m pretty sure you’d love coding on OSX.

      As for a port being easier, honestly, I’m not sure I would have been able to get recording and playback working on RG on OSX in the same amount of time that I got to where I am now with EdenX.

  6. This is great progress Guillaume – to be honest I thought you’d given up on this project, although I’ve often checked the blog for updates. As I posted before, I hope EdenX can eventually transcend its exisistence as a means of proving a point about Linux development, to become a standard armament for any OSX electronic musician’s arsenal. Believe it or not, OSX open-source standalone sequencers fill a niche which is currently quite empty, so you should have a large and eager audience awaiting.

    1. I won’t give up on this just yet, I’d like to take it to the point where it can decently edit a track in notation form, then call for other people to join in. If nobody is interested, then yes I’ll probably turn my attention to something else. But at the moment this is still a lot of fun, even though I alternate between this and my photography (hence the slow progress).

Leave a Reply

Your email address will not be published. Required fields are marked *