DMX Control and User Interfaces

[Hambone]

In Ableton Live, audio tracks can play at any tempo without pitch-shifting. You can input the desired tempo in the master track. When that scene is then launched, Live switches its master tempo to the tempo in the master track. Every clip playing (audio, lighting, video) now plays at that tempo (if you want it to).

 

http://img352.imageshack.us/img352/7696/picture27jb.png

 

I haven't found the granularity a problem necessitating in-betweening, but then my tempos are all 80-180 BPM.

[jfitzpat]

Sorry guys, I feel I'm being really thick here.

 

I understand how when you lauch a sequencer at has a beat clock set to some BPM tempo. I'm cool with changing the sequencer tempo changes the "speed" of everything. What I dont get is that if you have audio clips which are not at the master tempo, when you drop them in, how does a 160BPM audio clip get synced to a world view that prior to the audio clip was at 140BPM?

 

JJF - nice trick on CCs, doing inbetweeners. I've not seen or used CCs other than as stored values, either in show control (in which case they are discreet values at some event point) or the music sequencer way (ie changes in CC level recorded at the sequencers resolution).

 

Many movers these days have rate channels, so they must pose their own problems, in that ideally the rate would also need to be tempo related...? One day I must hire some movers and have some fun, still an area of theory for me :(

 

Conceptually, Hambone is basically:

 

A) Building libraries of light sequences (including moves, color, gobos, video, etc.)

B) Recalling the sequences in various order, sometimes on the fly

 

He currently records his libraries as MIDI sequences (DMX levels as CC values). Then uses an interesting 'improvisational' MIDI sequences to assemble and play them.

 

The two big advantages are that a) the overall tempo of library pieces can be altered (including moves and fades) and b) he can use tracks to layer library pieces together (strobes, video, movers).

 

The downsides are a) bandwidth and channel density, b) editing, and c) tempo range. Because the fades and moves are 'sampled' in MIDI CC messages, the moves get jerky when the tempo gets slow and 'jittery' if the tempo is too fast (hard to describe).

 

For users like Hambone (and others want to 'improvise' with more sophisticated fixtures and technologies) is that, unlike many boards for movers, we already can decouple time from scenes. We also are completely flexible when you break order. In fact, our LivePanel already could act as a four track implementation of what Hambone is doing - the upside being the library pieces are much easier to create and moves and fades remain very smooth across huge temp ranges. The downside was that temp for each library piece had to be provided by the user, making is more cumbersome to assemble things on the fly. So we came up with an interesting 'plug-in' model to let tempo come from other sources and for things to be set relative to it (double time, half time, etc.) It also gave us an opportunity for try out another feature set we've been thinking about for similiar users. Though I'm supposed to stay mum on those until 1.4 is released (soon).

 

Hambone's approach wouldn't be for everyone, but I don't think it is nec. just for dance floors either.

 

Regarding speed controls on movers. Since they are all vendor specific, most of the time folks leave speed at max. The console then generates positions at a high enough update rate so that slow moves are smooth. This is why Hambone's moves get jerky at low tempos. Occassionally I'll tweak motor speed in a cue - but typically only to get either a super down-and-dirty multi-part fade in one scene or to make the fixture quieter.

 

-jjf