Towards the Perfect Live Motion Graphics Performance Tool

I think Luz Studio has a lot going for it. The Create Digital Motion article Luz: Live Motion Graphics, Controlled by Anything, Free on Linux and Now with DMX sums it up nicely, so I’ll leave it at that.

I’m going to talk about where Luz Studio fails, and then tell you how Luz 2.0 is going to overcome those failures.

Luz Studio fails in usability.  The seven User Objects (Actors, Directors, Themes, Curves, Events, Variables, and Project Plugins) that make up a user’s Luz set are a great model and effectively encompass everything that is required to make a fantastic interactive visuals show.

In Luz Studio these seven types are presented in tabs, which is consistent and makes the internals beautiful, but it fails in that it does not convey to the new user which of these are immediately relevant and important to them.  The user interface also fails to convey the organization of these objects, presenting them as flat when in fact Directors logically contain Actors, and Directors are themselves contained and controlled by the Project Plugins.

Luz Studio uses deprecated technology.  Specifically, the Ruby-Gtk bindings project that Luz Studio uses to create the user interface has dropped OpenGL support.  Hint: OpenGL is important to Luz.  I don’t want to fight with upstream projects.  It’s a deal breaker.  This is why Luz Studio doesn’t work out-of-the-box in any Ubuntu more recent than 11.04 (released April 2011).

Luz Studio crashes. This is entirely due to the Ruby-Gtk bindings (or Luz’s misuse of them).  Ruby applications needn’t ever crash– that’s one of the beautiful benefits of an interpreted language.  Ruby bindings, written in C, are able to introduce segfaults and segfaults make kittens cry.  Luz has only seen crashes due to the Ruby-Gtk bindings, not any other bindings it uses.

Luz Studio suffers from a Stop-The-World pause.  This is caused by Ruby garbage collection (GC), but more specifically it was found to be caused by our good friend, the Ruby-Gtk bindings, which does a tremendous amount of difficult work every time Ruby GC is invoked.  With Ruby-Gtk included in a Ruby app, the GC times are almost half a second, without them they are unnoticably short.  Like under 1/100th of a second.

Luz Studio is limited to Linux.  While the original plan for Luz did involve an amount of ideological evangelism for the Linux platform, it would be neat as heck to be able to run Luz on OSX, at least.  It’s what many live performance musicians use, so it would open up the potential audience significantly.  (Windows, too, for the poor suckers stuck there.)  What makes it difficult for Luz Studio to run in OSX or Windows?  Gah, beating a dead horse here: it’s the Ruby-Gtk bindings.  The Luz Performer has always worked in OSX and Windows, because it’s a much simpler Ruby+OpenGL+SDL application.

Luz Studio is single-user.  One mouse, one user.  Friends get bored.  There was some effort at making Luz multi-user over a LAN, but this was triggering the Ruby-Gtk crashes more often, when other people did stuff, which was just intolerable.

Luz Studio is not live-playable.  This was the original goal of Luz.  Create and play visuals live.  What it is good at now is creating a toy at home, and playing it live at a show.  This is largely due to the long Stop-The-World pause introduced by Ruby-Gtk, and partly due to window management problems with Gtk OpenGL apps.

Gtk is not meant for live performance.  This was never a consideration for the toolkit.  The implications are subtle but important for Luz.  For example, the user is using a spinbox to change a decimal value from 0.5 to 0.7.  Gtk sends us a few change notifications… 0.54, 0.68, 0.7.  The changes in value are not themselves beautiful.  Wouldn’t it be great if the user could change values beautifully?

Luz 2.0

If you’ve been following along so far, then you might guess where this is going.

We’re dropping the Ruby-Gtk bindings.  The bindings served us well so far and I am personally very grateful for the work done by the Ruby-Gtk team!  It was quite a useful stepping stone, and Luz wouldn’t exist today were it not for this project binding the extremely beautiful Ruby language with the extremely beautiful Gtk toolkit.

No more Gtk bindings means no more Gtk, and we need a new way to implement a user interface.

Instead of picking a new cross-platform interface toolkit and dealing with a whole new set of problems, the plan is to implement one from scratch, using only Ruby and OpenGL.

A shockingly simple sounding solution that will solve all the problems listed above.

Work is underway on this, and while it’s a large undertaking, it’s coming along nicely  (It turns out the existing codebase of Luz is in fact quite perfect for creating a user interface library!)

The goals of 2.0 are:

  • Fullscreen, animated and beautiful interface.
  • Extremely usable and intuitive.  Usable by young people.  My target age is 4.
  • Smooth and performable creation of sets.  Creation of sets from scratch as a type of live performance.
  • Multi-user set creation, each with their own cursor on one screen, or on multiple screens on a LAN.
  • Able to load existing Luz sets.
  • Linux, OSX, Windows

This is what it looks like so far:


6 Responses to Towards the Perfect Live Motion Graphics Performance Tool

  1. designingpatrick says:


  2. beautiful. application is on the up and up. cheers.

  3. W3wt, I’m excited to see this growth develop 🙂

  4. Chikako says:

    Any update on Luz 2.0?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: