Luz 2.0 takes the pure-Ruby engine of Luz 1.0 and all its plugins, drops the GTK interface, and replaces it with a custom fullscreen animated interface. So go ahead and stay in beautiful color-world.
Luz 2.0 User Interface Design Goals
– stay with the visuals, no leaving play mode to edit
– show all edits immediately
– be as simple and consistent as possible
– all value changes should be smooth and “playable” for creating Luz sets live as a new form of performance
– all behaviors should live behind a checkbox that can turn them off: it allows for learning how something works without altering it irrevocably
– the most common operations should be easiest, for example animating a setting to the beat is a single click
– a simpler technology stack, making it easier to run Luz on OSX or run Luz on Windows (help wanted, contact me)
The Heart of Luz 2.0
This is the object editor, and it’s basically the only thing to learn, because all editing you do uses this editor, from configuring human input to tweaking the settings of pixel-bending shaders.
In this screenshot, we’re editing a rectangle actor which is showing a movie. The Scan Lines Horizontal plugin is selected, and its size setting is being changed.
Luz 2.0 is on GitHub. The goal is to make life more beautiful and fun, and so Luz is free and open source software, and you are welcome to project it on the wall at your next house party, to use it for live performance, even to earn money with it.
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.
It contains information about how Luz, which is written in Ruby (slow!) achieves 60+ FPS (fast!), and lots more about the how and why of Luz. The document allows comments, so please let me know your thoughts!
Luz is a live motion graphics editor and performer.
With this change, startup time is down from ~4 seconds to under 1 second. Mainly I think this is due to using separate builder XML files, as opposed to one massive glade XML file that I now believe was being loaded repeatedly (once for each toplevel window).
Now I need to figure out what happened to the Ruby bindings for GtkGLExt, and Luz will be able to run in Ubuntu 11.10 and up (bug).
Though I’m not on 11.10 yet, so any help would be appreciated!
I’m so happy about this added functionality! I want to publicly thank Zoom for such a great free update.
The Zoom H1 makes super high quality recordings, and now also serves as a high quality digital audio mic while connected to a Linux computer.
Performing the Zoom H1 version 1.x to 2.0 upgrade in Linux
In short, this fails.
Something about writing the H1MAIN.bin to the Fat32 file system in Linux causes the very brittle upgrade process to fail. It will notice the file and begin the process, and end with “WRITE ERROR”. Thankfully it doesn’t brick the device.
The solution is to:
copy your recordings off the device
format the card inside the device: hold the Trash button while turning it on, then confirm the format by pressing the Record button
copy the H1MAIN.bin file to the root of the device’s filesystem using a Windows computer (download Zoom H1 System Software Version 2.0 and unpack)
initiate the upgrade: turn on the device while holding the Play/Pause button, then confirm the upgrade by pressing the Record button (twice)
Once upgraded, the mic functionality is detected and works automatically in Ubunutu (and presumably other Linux distros), and shows up in PulseAudio as both an Input and an Output. This means you also now have two audio outputs.
The French, Serbian are Czech are well underway and could use a little more love.
Thanks for helping out!
Comments Off on ScreenRuler and Studly translators – French, Spanish, Brazilian Portuguese, German, Czech, Serbian needed | GNOME, Ruby, Ubuntu | Permalink Posted by Ian
Some languages *were* done, then I tried them in Studly and realized I had missed some strings.
Thanks for your contributions!!
If you’re interested in making desktop apps with a most beautiful and sexy programming language (Ruby), I encourage you to check out the code to Studly– it’s under 500 lines, fairly clear, and accomplishes a lot.
More screenshots: http://lighttroupe.tumblr.com
Posted by Ian 
GNOME Coder 