The biggest addition to this version is the ability to build cue sequences that are fired based on an absolute timeline. It has been clear for awhile that this was an important feature, but deciding how to implement it turned out to be non-trivial. Should there be a special group cue that fired its cues on an absolute timeline? If so, how should those times be specified? Should the existing wait times serve double duty? But how would they be distinguishable from “normal” waits in the workspace display?

The problems all boiled down to one thing: QLab has been designed explicitly to maintain loose relationships among cues. Cues tend to be very independent and flexible. This is handy for manipulating a workspace, but at first glance appears to be poorly suited to an absolute timeline, where each cue is locked into place relative to other cues. How the heck is a cue supposed to be both independent and flexible while simultaneously rigidly fixed in relation to other cues on a timeline?

With helpful input on ticket #144 I have chosen to implement absolute timelines as follows:

You are now able to specify two wait times for each cue: one after the cue and one BEFORE the cue. In addition, Group Cues now offer the option of starting every cue within the group when they are fired. These two independent features, when combined, allow you to put together a list of loosely related cues (for example, they need not be in any particular order within the Group Cue itself) that nevertheless are fired based on a strict absolute timeline.

The biggest drawback to this approach was that it pushed yet another column into an overly crowded workspace. What to do?

…offer the option of choosing which columns to display, that’s what. In general preferences you can now customize which columns of information you wish to display in your workspaces. So for those of you who don’t need absolute timelines, just turn of the Pre-Wait column and you don’t have to look at it.

Last but not least, I’ve decided to go ahead and throw the switch on the Universal Binary for the free version of QLab. (QLab Pro is not yet available as a Universal Binary because of the MIDI Cues.)

And…even laster but not leaster, I’d like to give a shout out to Mark Hartshorn, who, through a very thorough and detailed bug report, helped me quickly find and fix several bugs in the MIDI Cue. Thanks, Mark.

One big addition is that Group Cues can now be transformed into miniature Cue Lists inside other Cue Lists. See:

http://figure53.com/trac/index.fcgi/ticket/112

for a discussion of the impetus behind this. Basically, these mini Cue Lists give you more power by creating a Group Cue that stores some internal state. This allows you to achieve some designs that were not previously as easy to achieve. I haven’t written up docs for the mini Cue List yet (although the above ticket describes their behavior accurately), so if you have questions feel free to ask.

Aside from the 10.3.9 bug, this release addresses several important bugs in the Fade Cue. See the release notes for details. WARNING: It was necessary to change the behavior of the Fade Cues to fix one of the bugs. Please be aware that fades you have created in old workspaces may sound slightly different using this version of QLab. Update with care. (That’s why it’s beta software, folks!)

In other news, I’ve got MIDI messages firing successfully, as of yesterday. I need to write the inspector panels so you can control them, as well as the necessary bits to save them in the workspaces, and then I’ll be ready to send out a preview release of the upcoming QLab Pro to my MIDI testers. Onward and upward!

On the development front, I’ve turned my attention to MIDI. It’s coming along nicely, although naturally it takes a bit more time to get a big feature like this in place. As such, there will be a bit of an interlude before the next release.

I will be looking to find three or four committed beta testers for the upcoming MIDI features. If you are able to provide a thorough test of these features, and would be interested in doing so, join us on the mailing list where I will make the official call for testers when I’ve got something you can poke at.

You can assign any cue a hotkey in the “info” tab of the inspector. More than one cue can have the same hotkey, but if you assign a key that is being used in the key map (in General Preferences) you will see a warning that this key is in use and the hotkey will not function until the conflict is resolved. (Either by reassigning the key map in the preference panel or by reassigning the hotkey for the cue.)

Note that hotkeys do not respect cue sequences. Consider them “one shot” triggers. If you want to start an entire sequence, assign a hotkey to a Start Cue.

If you assign a hotkey to a cue list, it will behave as if you pressed the “GO” button for that cue list.

At any rate, the new playback controls are essentially complete, except for a few stubborn loose ends. I’ve been saying to myself “in a few days” since last weekend, but I really do think it will be just a few more days. So sit tight and watch this space.

(* For those reading abroad, today was the High Holy Day of American Football: the Superbowl.)

I’ll be focusing in the next few days on ticket number 56. Once I do have a roadmap to 1.0, I’ll be sure to sum it up here.

The current implementation of cue numbers is not a complete solution—I have not yet included automatic generation of cue numbers, for example. But you can renumber selected cues by a user-specified increment. (Would one call that “semi-automatic”? Hm. Sounds violent.)

I then expect I’ll start narrowing down exactly what features must be in version 1.0. Since feature requests have leveled off in the Tracker, I’d like to nail down a concrete roadmap on which to focus my efforts in the coming weeks. I want to make the basic feature set solid and powerful, and spend some serious time building up my testing framework and remote debugging tools. My goal is to keep development focused, to keep delivering steady improvements in a timely manner. Not every feature request will make it into 1.0, but with a little luck they won’t be too far behind.