DMX Control and User Interfaces

[dbuckley]

... As far as our whole 'open' approach to tactile input, I think we are pretty much it on any platform.

Well, your list of DMX input tricks supported looks the same as PCStage's list, so you're certainly not unique, and I cant believe that X1 and PCStage are the only two products with this featureset, surely...

 

 

These posts originally started life here.

[jfitzpat]

... As far as our whole 'open' approach to tactile input, I think we are pretty much it on any platform.

Well, your list of DMX input tricks supported looks the same as PCStage's list, so you're certainly not unique, and I cant believe that X1 and PCStage are the only two products with this featureset, surely...

 

It has been awhile since I looked at PCStage, but the last time I checked DMX input was primarily used with a 'mapping' function. I didn't know that there are equivelents for our extended profile (transport control, automated sections, etc.) Also, even for a basic usage (ex dipless submaster mapping) dimmers seemed like they would behave the same, but not intells. In fact, aside from a 'snap' vs. 'fade' option for named faders, I don't recall any real core support for intells at all.

 

But, I'll rephrase - among systems that strive to be viable alternatives to, say, a 3 universe show on a GrandMA, most appear to have gone the route of vendor specific wings. I understand why, each of us tries to address the problems a little differently, and a dedicated tactile surface is a nice extension. But, for the reasons stated, we went 'generic'. And, to the best of my knowledge, none of the others (Maxxyz PC, Light Jockey, Vista, HogPC, or even lower end stuff like Compuware) lets you operate intells from an external DMX controller with the same mix-and-match/any-speed/any-order approach we do.

 

-jjf

 

Edit: I just looked at the PCStage Web site and one thing I will give it is that, like us, there is an external API. Although I haven't looked at theirs in detail, we've used ours to support some pretty unusual input devices. You can also build some interesting playback/scene usage things on top of it (we've got one user who built his own playback stack on top of it).

[dbuckley]

It has been awhile since I looked at PCStage, but the last time I checked DMX input was primarily used with a 'mapping' function.

Yes, mapping is one technique, which allows an input DMX512 level to control a fader, or a submaster, or a crossfader. You can also assign change of DMX level to a trigger, which can then issue any desk command. And yes, PCStage isn't a "from the ground up" movers desk, its has a bit of support for movers (the "Robotics Desk"), but it wouldn't be your first choice for a movers desk in any known universe, especially given it doesnt have an effects generator at all, and esecially not a morphing bunny like yours! Neither does the author seem keen to add much in the way of movers, which whilst frustrating is ok, I guess: what you have is truly excellent control system for a category of show (which I could define as those that you would otherwise do using SFX show control edition plus a ETC Express and feel frustrated with) and then hit a wall :(

 

I think my underlying point here is that there is no monopoly on good ideas, and very little in terms of features that are unique, or perhaps stay unique. In terms of control surfaces, folks like them. If you have a PC based control system and dont, can't or won't manfacture wings for it, then how do you satisfy the desire folks have for physicalness? By supporting other peoples physical interfaces, and today the two available interfaces are DMX consoles and MIDI. Almost a no brainer... As to why other makers dont support more universal input - they sell wings.

 

I note you now have a low cost interface - very nice :D There are lots of folks who still dont get that there is no decent really cheap or free control software out there, but there are several options now at around that price point, options that really do work.

 

Added:

 

... PCStage Web site and one thing I will give it is that, like us, there is an external API.

I take it you're talking about the new COM interface. Yes, this is new, recent, and to me, anyway, puzzling.

 

PCStage is a command driven tool, you can make it jump through almost any hoop by issueing a text command into its parser thingie. You can issue commands to the thing programatically via two TCP interfaces (telnet and web), and there is also a plug-in API so that one can build ones own plugins and they can issue (and receive) commands. I just dont get why the COM interface. Other than the author's history - to my knowledge the author has never touched a lighting board in his life. PCStage is his ongoing experiment in user interface design concepts and large software project management...

[jfitzpat]

I think my underlying point here is that there is no monopoly on good ideas, and very little in terms of features that are unique, or perhaps stay unique.

 

I'm sorry if my message came across otherwise. I didn't mean to imply that it was genius on our part. I just meant that, for various reasons, most vendors doing higher end products have opted to do their own surfaces. We went a different route because of our mental model of the target user.

 

I understand both the engineering side and the business side of add-on surfaces. But in this case, I thought that it was an important tradeoff. I'm just as happy seeing a high school use us as a moving light 'add on' to their existing ETC console as watching us run a huge show. I don't care if the high school kid only uses the cue editor for a few minutes and then largely forgets us, that still meets the original product goal.

 

On the point of commercial vs. free. I think that initiatives like Ben's can serve some very important purposes. What I would really like to see is more people interested in controlling lights in new and innovative ways than trying to collaboratively create a free clone of something that has already been done - that is why I added the positive comment about PCStage's experiments in automation (rather they are successful or not).

 

Again, sorry if my other post conveyed more than 'most seem to be going another route'.

 

-jjf

[dbuckley]

I'm sorry if ...

No apologies necessary, I think we've just bumped into a medium limitation rather than a situation requiring apologizing for. Sometimes, pubs are better than forums :D

 

On the point of commercial vs. free. I think that initiatives like Ben's can serve some very important purposes. What I would really like to see is more people interested in controlling lights in new and innovative ways than trying to collaboratively create a free clone of something that has already been done - that is why I added the positive comment about PCStage's experiments in automation (rather they are successful or not).

The big problem is that it seems it is non-trivial to build a meaningful control system. You've been at this longer than many blue roomers have been alive, and PCStage's author started with a simpler product in (I think) 1997. Many of the free desks have yet to get to a dipless crossfade. So kudos to those who wanna have a bash at it, but before you have to get to the functionality of an M24 before you can contemplate a hog, and that doesnt get coded in five minutes.

 

In terms of the wider issue of control - this is one of my big frustrations. Now I have to be careful with what I say, as many blue roomers dance to the beat of the show-caller's drum, and any time you mention "automation" or "integration" they see P45s and UB40s, which I fundamentally disagree with. I love (both conceptually and doing) "interactive" theatre. I like making the performance (and auditorium) space an input to the control system that then changes the space. I've been fooling about with this for many years, even trivial stuff like triggering the sample when someone closes a door to make it sound "real", not like a cardboard stage door. Light switches that really do work.

 

PCs make this possible and affordable. MIDI lets us connect stuff up. Its fun, cool, and generally artistically worthwhile, and do it right it adds a layer of "naturalness" to a show that is hard to do otherwise.

 

I know the sweedish distributor of PCStage has done a number of jobs in museums, using triggers to change lighting and playback multichannel audio, no-one has asked me to do this - yet :( But its the same tricks, just in a different space and manner. I'm rambling, aren't I... Check out my webpage (link in sig) for some odd PCStage stuff...

[ben.suffolk]

On the point of commercial vs. free. I think that initiatives like Ben's can serve some very important purposes. What I would really like to see is more people interested in controlling lights in new and innovative ways than trying to collaboratively create a free clone of something that has already been done - that is why I added the positive comment about PCStage's experiments in automation (rather they are successful or not).

 

Personally I believe that technology should be like victorian children, i.e. seen and not heard. It should be there with all its power and efficiency to get a job done, but it should not get in the way. The user interface is *THE* most important part of a system as far as I am concerned (obviously the behind the scenes technology must actually do what it says on the tin). Thats where the LightsOn project fits in, it is the behind the scenes technology and it will do what it says on tin, every time and without fail.

 

Its aim is to create a reliable framework for developers to create great software with, be that free or commercial (Which is why I used the BSD license not that evil communist GPL one - but thats a very different topic of discussion I think). If the developers of the software that use it are short sighted enough to copy an existing user interface (and thus maybe its flaws) then I think thats a shame, and an opportunity missed. My reasons for creating this project, and donating my time and code into it, are to hopefully bring the standard of lighting control via computers up several notches, and to seed the variety of approaches to user interfaces by allowing developers to spend their time thinking about and implementing them and not having worry about how to make it all work.

 

Ben

[jfitzpat]

Personally I believe that technology should be like victorian children, i.e. seen and not heard. It should be there with all its power and efficiency to get a job done, but it should not get in the way. The user interface is *THE* most important part of a system as far as I am concerned (obviously the behind the scenes technology must actually do what it says on the tin). Thats where the LightsOn project fits in, it is the behind the scenes technology and it will do what it says on tin, every time and without fail.

 

If it was not clear, I was making a seperate point - not saying your effort is a collaborative clone.

 

The problem I have with collaborative clones is that they do nothing to further your 'victorian children' goal. They mimic existing solutions instead of exploring new, possibly more seemless and transparent ones.

 

Your emphasis on reliability is also admirable. Now that I think about it, the quality of many of the free/near free offerings is probably more troubling than their lack of innovation and features. Don't want to have any new ideas? Fine, but how about not crashing when I drag an icon...

 

Good Luck,

-jjf

[dbuckley]

I do all of my lighting on a Mac with a MIDI>DMX interface, ... Ableton Live's Follow Actions, Virtual MIDI, MIDI effects, Live Clips, and all lighting under automated tempo control, I venture to say that I can do a lot more.

Every now and again I find it a tad frustrating that I am a long, long way from most of you guys. I read in the Arkaos thread what you are doing (or at least what you are doing whatever it is you are doing it with) and its clear you are in a different space to almost everyone else in the blue room, including me, and since I'm off on a limb thats interesting from the getgo.

 

I just dont get Ableton live. I've looked at the web site, it seems to me that its a music sequencer, so I guess it has tracks that can be MIDI or audio, all fine, but whats the follow actions stuff all about, and is it doing something clever in its own right??? Or have you programmed your rig in there on aa per track basis?

 

 

 

If the developers of the software that use it are short sighted enough to copy an existing user interface (and thus maybe its flaws) then I think thats a shame, and an opportunity missed. My reasons for creating this project, and donating my time and code into it, are to hopefully bring the standard of lighting control via computers up several notches, and to seed the variety of approaches to user interfaces by allowing developers to spend their time thinking about and implementing them and not having worry about how to make it all work.

Those are lofty goals, and I do indeed wish you well.

 

I agree about user interfaces, and fortunately there do seem to be differences in this respect. I can only really talk about the product I know pretty much inside out, and quote from a very early posting I made to the support list:

 

Although I find [the user interface] PCStage "odd", and more oddly, I can't explain why, its really growing on me.

It's odd because it doesnt come across as anything you've used before, as it merges the traditional desk concepts of memory and presets, so its (depending on your preferences) a one preset desk with odd memories, or an infinite preset desk with simplistic memories. What it isn't is a two or three or four or eight preset desk, except that it has the concept of the current preset, fading to an incoming preset. And it then layers this as many times as you want.

 

As I say, its a bit odd, but now I'm used to it, its an interface that works for me.

 

So yeah, figure out another (possibly better) way to do it. Most developers haven't, and possibly unfortunately, most users are very happy with a computer representation of a two presetter, as that is comfortable and easy to get on with. But user interface is indeed everything, but unfortunately so is reliability and features :)

[Hambone]

I do feel like I'm from another planet inventing my own way of doing things... not sure whether that's a good or bad thing!

 

Live IS primarily a live audio performance app, but doing lighting and video works really well. Lighting and video clips can be played directly from a MIDI controller or sequenced. Live's Follow Actions let you sequence and control, either manually, automatically, randomly, semi-randomly, etc what order the clips are played in. All of the audio, lighting, and video (including remote pan/tilt/zoom camera control) can be contained in a single 'scene,' which can again be launched by a MIDI controller, sequence, or another Follow Action. Once you get scenes, clips, and follow actions interacting with each other, and because clips can automatically launch other clips which can launch other clips (you get the idea) the possibilities are huge (and will keep you awake at night!) And because all clips follow the master tempo, everything remains in sync, irregardless of tempo.

 

I do a mixture of presequenced audio, lighting, and video, and play the rest on the fly (normally while I DJ requests). Because one MIDI button can launch a complete integrated audio, video, and lighting sequence that automatically beatmaches to the current song's tempo (which can also be automated), it can be as simple or complex as you like.

 

Sorry for hijacking the thread!

 

(P.S. I've always wanted to mountain bike NZ... maybe I'll pop over and explain it in person!)

[jfitzpat]

I do a mixture of presequenced audio, lighting, and video, and play the rest on the fly (normally while I DJ requests). Because one MIDI button can launch a complete integrated audio, video, and lighting sequence that automatically beatmaches to the current song's tempo (which can also be automated), it can be as simple or complex as you like.

 

Well, technically no. You are using a MIDI -> DMX converter, so you can only generate every other DMX value (MIDI CC values range from 0-127). Also, the MIDI baud rate is 31,250 and uses multiple bytes per controller change. DMX is 250,000 and uses one byte per control value. So, you really can't get to all features on the majority of intelligent fixtures and your total channel density can't get particularly high.

 

Even with ArKaos, the VJ DMX version gives better granularity of control via DMX than is available via MIDI.

 

I'm not saying it isn't an interesting approach, I'm just saying it isn't very scalable, doesn't give access to all the features of the equipment, and almost certainly is slower to initially program.

 

-jjf

[dbuckley]

... I'm just saying it isn't very scalable, doesn't give access to all the features of the equipment, and almost certainly is slower to initially program.

All of which is undoubtably true, but it seems to me that Mr Bone is treading a path here that isn't well trodden. In order to try and accomodate the scale of what he's trying to achieve, he's misusing a music sequencer product. This brings strengths and weaknesses, some things it clearly does very well, some things (eg driving lighting through a NJD MIDI->DMX I/f) it does less well, but the solution is integrated, and (and I think this is the important bit) has one set of recallable files per track, so on loading the music, the lighting and other instruction comes with it.

 

It seems quite hard to be able to split this up and do chunks of it better without losing convenience.

 

Even using the package I know backwards would make this an uphill battle. It can play WAVs, it can do lighting, it can do all the MIDI known to mankind, it can do a bit of video, it can even hold it all together to some extent, but it cant go from track to track, you have to load your show elements up first, as loading a new show trashes playback in progress, as thats part of a show. The fact that it is better in some respects, and easier in others doesnt overcome the basic weakness that as a live performance tool it wouldn't work. Better may not be good enough.

 

One of those things that bugs me <rant> about lighting is tempo, and lighting not being on the beat with the music. This has especially happened over the last few years as movers become more popular, there is this mentality that lots of flashing movers is good, and they are never on the beat, and it bugs the hell out of me.</rant> Beat is a problem I've been wrestling with for years, and elsewhere on this very forum are stories about me wiring up bass drum pedals so I could have accurate beat tracking. Thus Ham's notes about tempo tracking interest me, and I want to know more. Where the music source (or at least beat source) is a sequencer, theres MIDI clock, and MIDI clock is just the best for syncing lighting to music. But in the absence of such an electronic rythmic source, it all gets a tad harder. Do you manually (which as JJF suggests wont be easy work) line up MIDI events to the beat, or is there some flashy trick going on.

 

(And I still haven't tried a red sound beat detector...)

 

This is all so far I'm surprised a :) or even :( :huh: :o ;) :mods: :mods: hasn't / haven't split us off to some hitherto unknown corner... (yes, that was the Mod Squad)

 

You called? I was putting this one off because I wasn't quite sure where to split it without messing it up too much.

[ben.suffolk]

If it was not clear, I was making a seperate point - not saying your effort is a collaborative clone.

 

I didn't think you were having a go, but it looked like it could easily be misread, so I thought I'd use it as an opportunity to be a bit more clear about the project.

 

Good Luck,

 

Thanks.

 

Ben

[Hambone]

Well, technically no. You are using a MIDI -> DMX converter, so you can only generate every other DMX value (MIDI CC values range from 0-127). Also, the MIDI baud rate is 31,250 and uses multiple bytes per controller change. DMX is 250,000 and uses one byte per control value. So, you really can't get to all features on the majority of intelligent fixtures and your total channel density can't get particularly high.

 

Even with ArKaos, the VJ DMX version gives better granularity of control via DMX than is available via MIDI.

 

I'm not saying it isn't an interesting approach, I'm just saying it isn't very scalable, doesn't give access to all the features of the equipment, and almost certainly is slower to initially program.

 

-jjf

 

Agreed! I'm only using 15 relatively basic fixtures, with no more than 7 DMX channels per fixture. I'm sure if I attempted to use the same system on a larger scale, I'd run into a MIDI throughput limitation. And there is the loss of one bit of resolution in the translation, too. I haven't found this to be a problem yet.

 

And although the initial programming took some time, it's very quick now with Live's drag 'n drop Live clips. Drag individual pan, tilt, color, gobo, rotation, and shutter presets into Live, drag the resulting six clips back to the browser, and that combination is ready for use and saved for future use. Drag that clip into Live with flood, wash, strobes, etc and a video clip, and an entire lighting and video scene is ready, which again can be dragged back into the browser and automatically saved as a lighting and video combo that can be launched with a single MIDI keystroke. Even combine audio with the clip, if you want.

 

David - regarding beat-matching, since all of the lighting is controlled by single CC values to set a DMX parameter, or a CC curve for pans/tilts/fades/etc, they will automatically follow Live's tempo. When a scene in Live is launched, the MIDI tempo is automatically set. There's no tapping, etc. Now, a one-measure pan sweep is nothing more than a MIDI continuous controller curve from 0-127 over 4 beats on a selected MIDI CC channel, which the converter maps over to 0-255 on the corresponding DMX channel. If the tempo is 120 bpm, the sweep will take 2 seconds. If the song tempo is 60 bpm, it will take 4 seconds. It's tied to tempo, not time. It will even track tempo changes. So my Live clips that I either sequence and/or trigger manually will always be beatmatched. And you don't even have to trigger then on time if you don't want to. You can quantize the launching of a Live clip to whatever timing parameter you want. I quantize many of mine to a measure, so all I have to do is to launch the clip any time within the preceding measure, and Live will wait to launch the clip on the downbeat of the next measure to make sure that everything stays beatmatched. It's not just lighting. The same one-measure CC sweep that did the scanner or laser pan can be used in Arkaos to do a beat-matched video effect, or in Live to do a beat-matched filter sweep to the audio. It makes it easy to choreographed the lighting, video, and audio to all work together. I'm also using a wireless PlayStation dance mat to let the crowd launch lighting, video, and audio clips for a bit of interactivity.

 

I'm working now with Plogue Bidule (an audio/MIDI modular analysis plug-in) to generate a lot of the CC data automatically on the fly with no pre-programming. The FFT analysis of an incoming audio file allows you to assign different thresholds and frequency bands to generate the CC data, which again control the video parameters and the lighting.

 

I agree that this is completely amateur stuff, and apologize to the pros on the forum. (Dodging incoming Mod Squad...)

[jfitzpat]

ut it seems to me that Mr Bone is treading a path here that isn't well trodden.

 

[snip]

 

It seems quite hard to be able to split this up and do chunks of it better without losing convenience.

 

Agreed. Certainly his efforts inspired me, both to write a little white paper on MIDI->DMX and in the design of a new plug-in arch. for our Live Panel (in 1.4, coming soon).

 

In some respects, we are better suited to this 'reuse snippets at different tempos', since we already decouple time from scenes (a whole different subject I've always felt strongly about). But even on a more conventional mover board I can envision some interesting features growing out of this sort of usage.

 

-jjf

 

Edit: Hambone, one issue with your implementation (MIDI) that I wanted I wanted to elliminate in our plug-ins is 'granularity'. If you cange tempo a modest amount, sending CC messages with value information works. But, as you stretch time (tempo) in both directions to a greater degree, it falls apart (example, you drag everything down to 1/4 speed, instead of light movements slowing down proportionally you get jerky movement. We generate 'in-between' on the fly anyway, so I liked the idea of always generating changes at the highest granularity possible and then using tempo information to change the spacing/timing of endpoints.

[dbuckley]

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 :(