Leonard Ritter

µ (mjoo) is a new kind of live composition software for the Linux operating system, introducing ZUI interface concepts.

It seems the more I am thinking about, the less sense makes a single application that makes use of the ZUI desktop metaphor. What I really want is an entire working environment that allows me to work like this - zooming and panning around on an infinite, infinitely zoomable, persistent 2d plane. After all I'm going to require visual representations of files and network data within the program.

From my experiments so far this makes sense: it is rather a question how to arrange data in such a way that it comes naturally to an user, but the paradigm itself is unquestionable. Still, it remains an experiment. I'm a bit fed up with todays modal user interfaces, and reading Jef Raskins Humane Interface assured me in my decision to do some, ahem, original research.

So, mjoo is going to become a ZUI desktop. The sequencer part will be reintegrated once the basic desktop interface has been set up. As you know I'm also working on another music application, Mute, which is going to serve as a preliminary replacement for my real needs ;)

Writing a ZUI desktop is easy. You take the modal desktop approach, and cut away all the modal stuff. Everything is always available. There is no saving and no loading, but infinite undo. Since applications are also modal, there will be no applications, but only widgets representing data. I'm going to write a detailed description soon. Have a look at the Wikipedia ZUI site for some more information.

I had some look at similar projects. lowfat by MacSlow looks interesting, but too playful. It seems to be focused on document viewing, which is not my goal. Mjoo should incorporate a file organizer, a web browser (gecko backend?), a mail agent (evolution backend, perhaps?) and some other stuff. All other projects I've looked at are kind of outdated. There is no hardware acellerated rendering, which in my opinion is crucial for such an app.

I have the choice between C/C++, mono and Python (those are my favorite tools).

C would help to keep the system fast, but also means a longer development time and, from my experience, opposes the ideas of extreme programming. In case I make some design mistakes, it's going to cost me a lot of time to fix these. I would not have much time to try out different approaches. Besides that, C/C++ does not help much to write secure and stable code. Custom memory management would also be required.

Python looks like a better choice. I wrote mjoo as a compound of C++ and Python code, with the frontend being rendered by Python, and all the hard dsp work done in C++. There are lots of bindings available, it is easy to get along with, scales well. However it gets quite slow at some inner loop problems such as rendering a lot of objects or dsp code, which means that computation heavy tasks need to be moved to a C++ library at some point. For interfacing between Python and C libraries, I use ctypes along with a gccxml-based h2ctypes script that I've written to generate Python imports from C headers. Layered on top of that is a ctypes2classes script which can generate classes from a flat import list.

Finally there is mono, with which I've had not much experience so far, and its currently favored languages C# and Boo. I'm pretty sure that mono is worth having a look at, and that it offers a good blend between performance and ease of use. Just as with Python, the code would run on both platforms without many changes. It's just that I don't know much about it and haven't had any experience with it yet. I assume that, for cross compatibility, Gtk# needs to be used.

So, this question remains open. I tend towards what I know best, Python. Results have a higher priority for me than performance.

For the libraries, I plan to use OpenGL directly for the rendering. I was thinking about using Cairo, however I'm afraid it will not be accellerated on Windows and other systems. I will use PIL for font rendering and image loading. wxPython will be used for setting up OpenGL contexts and windows, and might be replaced by something more basic in the future.

The first use of mjoo will be to serve as a file browser. I'm thinking of a gdmap like interface. This will also be a good chance to implement level of detail stuff, which is badly needed for such an application.