Lighting Control Prototype

[Biskit]

W.r.t features: why not try something new, thats not just mimicking lighting desks how they currently appear. If you're on a PC based solution, use the fact that you have a nice monitor and have a lot of visuals / graphics available to you easily....

 

Just a thought... Perhaps a touch-screen designed interface would be nice. One of the things I dislike about many current PC based desks is that you have to click around with a mouse to control things. In principle, I guess you could use any software with a USB touch-screen monitor, but the problem is if the software is not designed with this in mind, on-screen 'buttons' may be too small to hit reliably, or may require 'double clicks' or 'right-clicks' which are inconvenient on a touch screen, etc.

 

These are all GUI considerations though.

 

In terms of actual features, I guess you'd start with the basic function of adjusting individual channels to create a scene, saving as a memory, and having some means of playing it back. Then perhaps the ability to create chases. Then being able to adjust fade in/out timings and crossfade type. Then being able to create a theatre-stack of these memories. These functions would apply to software intended primarily for theatre use with mainly generic dimmers. If you want moving light capability, or more of a 'busking'/rock-n-roll style, you'll want to think about pallettes, shape generators, instant playbacks and so on.

 

I agree with Wol... see if you cane think of something innovative that isn't offered by existing products. Above I've listed the standard features available on commercial desks of various types. These are the kind of things people would expect so if you can add to the list, all the better!

 

Ben.

[kev_bite]

Perhaps a touch-screen designed interface would be nice. One of the things I dislike about many current PC based desks is that you have to click around with a mouse to control things.

 

I really like that idea, never really thought of doing it that way. I have created a few touch screen GUIs for a manufacturing company I use to work for, these worked really well with numptys using them as it makes things even more obvious of how to use. also lots people having tablet PCs as these are more widely available now and not at silly costs.

 

I need to think of something original as you guys said, and as my uni project is mark on original ideas and not just copying what other people have come up with before. but the basic elements of a lighting controller have to still be there.

 

Cheers again for your ideas!

 

Kev

[kev_bite]

From my previous post a while back.

 

If any of you guys have the time, id appreciate you filling out my questionnaire

It doesn't require any sign up and is totally anonymous

 

http://freeonlinesurveys.com/rendersurvey....gzuexkcel529402

 

Thanks Again :blink:

 

Kev

[Dmills]

http://freeonlinesurveys.com/rendersurvey....gzuexkcel529402

 

Well I have a few issues with your survey methodology, not least that the very first question makes a false assumption:

"As there is no dedicated software for a PC based live lighting controller on the market today", well even if we ignore the fact that most people doing lighting desks use some variation on a PC internally (ETC, Strand, Compulite, ADB the list goes on and under the hood most of them are PCs), I can think of at least half a dozen variations on 'software plus some sort of DMX output dongle' out there being used.

 

I am afraid that IMHO the survey gets no better from there.

To just consider the software and a dongle completely misses the point to my way of thinking. The fact is that a desk without a fairly specialised control surface will be too damn slow to be usable for most people running serious shows (This is why none of the mostly software products have serious traction among operators). Ideally I want one button per function in some kind of sane layout, with encoders and pots as required.

 

The actual software is just by and large not very interesting any more, pretty much everyone has sane stuff and pretty much any desk at a given price point (and aimed at a given market) will do similar sorts of things.

 

The things that would interest me that don't even appear on that survey (Just some thoughts):

 

Reliability, it is no good to me if a malformed command or an error in a fixture definition can take the whole system down.

 

Macro language (Turing complete please) with hooks all over the system, possibly something lisp like might work well and it is about the easiest of things to parse (Think recursive decent). Actually having the bulk of the system implemented in the macro language would add a great deal of power, especially if something like the emacs 'advice' function was implemented (this lets you insert shims easily into all sorts of actions).

 

Actually, having the language directly exposed on the command line would add a great deal of expressive power as you could write entire subroutines and then execute them directly.

Python or scheme might be other reasonable choices, but in any case you need a GC with a well bounded response time.

 

It would be nice to have the ability to do things like define a colour scroll that knows there are dark colours at positions 4, 11 and 12 and that the one at position 4 is a double frame, so it should cycle between 4 and 5 if the position is 4 and the lamp is at greater then 25% and should start the fan at 40% level unless it is one of these frames where we need the fan when the level exceeds 20% .....

it would e nice if this scroll definition worked with any scroller.....

The fixture definition itself almost needs to be a full featured programming language.

 

The thing needs to be network aware, multiple boards are very very common these days.

 

Whatever you do (even if it means writing the bloody thing in assembler!) do NOT make me wait for the desk to do stuff, the desk is not 'busy', I am busy, the desk is annoying!

If you cannot make it happen nearly instantly (and why not?), at least let me continue doing things, the back end can catch up. On that note, modal dialogues, just say no! I get to control keyboard focus, taking it way from what I am working on is rude (and mostly unnecessary). Don't forget that a lot us us like to be watching the stage not a monitor screen when running a show, stuff that pops up and changes the meaning of buttons is **BAD**.

 

A low light mode would be good (switch the screen to black with reds and browns for text) as sometimes not having your night vision totalled is a good thing.

 

Just a few thoughts.

 

Regards, Dan.

[Tomo]

Your survey is very limited in responses, so I thought I'd answer here where I can give you more information.

(Read - I'm bored right now)

 

*1) As there is no dedicated software for a PC based live lighting controller on the market today, do you think it would be useful if there was?

There are a multitude of PC-based live lighting controllers in the market. Some of them are even free!

eg Chamsys MagicQ, Freestyler, ShowCAD, to name but a few.

 

*2) What would you say is the most important factor of a live controller?

The facepanel. All lighting consoles live or die by their interface.

In a 'live' situation, multiple simultaneously available playback options are required.

Unfortunately this means that a pure PC is a failure before you even start, because they cannot handle more than one mouse-pointer (whether mouse/touchscreen/trackball etc), and keyboards can only handle a maximum of between ~4 and 10 simultaneous keys, depending on keyboard model and the keys in question.

 

*3) When controlling lighting live, how many universes do you use?

Between 1 and 12 so far.

 

*4) When programming intelligent lights, do you think that fixture personalities are helpful to creating a lighting show?

They are essential.

Any console that claims to control moving lights *requires* fixture personalities. One could consider it part of the definition of a moving-lights console, another being palettes.

 

5) If the Live controller had personalities, would it be useful if you could create your own? if so how?

Yes. I want to make them in the console and have them immediately work, so I can check I did it right and fix my mistakes.

 

*6) Rank the following programmable items in which are more useful when controlling lighting live (1 being most useful):

1-Scenes

2-Pallets

3-Chases

 

You've missed Sequences (eg theatre stack), Submasters, Multiple Playbacks etc

There's a lot more to a console than simple scene-setting.

 

*7) What sort of event do you normally control live lighting?

Theatre

Live Band – Rock

Live Band – Other

Night Club

Cruise Liner

 

*8) What types of lighting devices do you use?

Dimmers

Scanners

Moving Heads

Smoke Machines

Haze Machines

Strobes

 

*9) What output protocol do you use from your lighting controller when controlling lighting live?

DMX512-A

ArtNet

EtcNet

Streaming ACN

 

I might point out that ETCNet2 and ShowNet are both proprietary protocols - you would need to arrange a suitable licencing arrangement to use either of these directly in a PC application.

I'm not sure what ABD is, unless you mean ADB's ADN system for dimmer feedback and configuration?

 

*10) Do you use Devices with 16bit channels?

All modern professional moving lights have 16-bit pan and tilt.

 

*11) Do you think shape playbacks are useful for quick programming?

I'm guessing that you mean dynamic effects, also known as shape-generators, where you set a centre-point and the attribute(s) move in a predetermined path around that centrepoint.

 

Yes, they can be very useful - but they are getting to be a bit 'old hat' as you can get fully-featured shape generators in a sub-GBP 2000 physical console, so a PC-based one would have to be better!

 

12) What playback shapes would be useful when controlling a live lighting show?

Depends on the show. A fanned out circle is often useful, other than that it's whatever looks good.

There's around 20 commonly used in modern consoles, plus the various standard functions (Sine, Ramp, Square, Sawtooth etc) that can be applied to individual attributes.

 

*13) Before an event do you use a visualiser to program part or all of the show?

For a live show, never - I don't have time.

For theatre, sometimes, but rarely. Again, because I usually don't have the time.

I'd want it to be an option though.

 

*14) When using a PC based controller, do you use different types of output widgets?

I generally use the one built into the lighting console, or an ETCNet2/StreamingACN network output node/Gateway.

 

Final comments:

At the start of this survey (Q1) you assume that PC-based systems don't exist.

In Q14, you assume that they do and that the respondant has used them.

 

I suggest you go out and do some proper research into what systems already exist, their capabilities and most importantly, their limitations.

 

You also need to spend more time determining the questions and answers for your survey.

For example, in Q14 "Yes/No" tells you nothing. You actually want to know which DMX-output dongles it's worth supporting in a theoretical PC-based system, so you should list available options and ask them to select the one(s) they use.

 

(Oh yeah - VB.NET isn't anywhere near powerful enough for a real-time control system. It's more-or-less ok for rapid-prototyping and one-off projects, but the overheads are huge.)

[TheSwami]

Survey issues not withstanding, I think it's an admirable goal to attempt to put together some lighting control software. While there's lot's of good things out on the market, I'm sure there's always room for improvement.

 

I busk some large scale functions/dances/parties, and the one thing I'd really like to see in a piece of control software is the ability to easily customize what shows up on screen. Most consoles/pieces of software will pull up a list of, say, focus palletes (or color, or beam, or whatever). Some consoles with built-in touchscreens (or those designed to be used with touchscreens) will even make each pallete its own 'button' onscreen, making it easy to switch focus points easily.

 

But I'm usually not changing the focus of too many things in quick succession. I'd rather have a display with label-able, clickable buttons like "VL 2Ks sweep," "All on Stage," "Moonflowers Only," "Movers Out," - each one an effect, focus/beam/color preset, intensity change, or cue, or maybe many of above. I don't need all my focus palettes onscreen at once when I'm running live; I need all the looks that I want to use for "Bohemian Rhapsody" onscreen, easy to access. I'd love to see a program/console that allowed the end user to easily build this kind of 'busking-palette' for themself.

 

73

[Nick S]

I learned a bit of programming in my Electronic Engineering degree, both in C and Assembler, and I have a lot of respect for programmers who can bleed every bit of function out of limited hardware. I'd argue that doing something like this should gain higher marks than a scheme with possibly more function but inefficient code justified becuse today's PCs are so ridiculously powerful that it doesn't matter! Perhaps I'm just old fashioned?

 

Ye I see where your coming from, my degree is on Software Engineering so its solid programming, but there's no point in writing my program in c/c++ as even cheap 200quid laptop will be able to cope with the work load.

 

Whoah - here be dragons! That's a dangerous assumption to make, and I've seen it result in a ton of god-awful code (I grade a lot of undergraduate CS coursework). A lighting control application needs zero latency and perfect timing - you may find yourself being forced to use a fairly low-level language for certain functions.

[DonkiDonki]

But I'm usually not changing the focus of too many things in quick succession. I'd rather have a display with label-able, clickable buttons like "VL 2Ks sweep," "All on Stage," "Moonflowers Only," "Movers Out," - each one an effect, focus/beam/color preset, intensity change, or cue, or maybe many of above. I don't need all my focus palettes onscreen at once when I'm running live; I need all the looks that I want to use for "Bohemian Rhapsody" onscreen, easy to access. I'd love to see a program/console that allowed the end user to easily build this kind of 'busking-palette' for themself.

 

73

 

 

You mean something like the "Execute" window on MagicQ? You can configure this screen layout with whatever buttons and features you like. (I believe this is one of the few features that are unlocked when using the software with a Chamsys Wing or DMX ouput device)

[tvi675]

You mean something like the "Execute" window on MagicQ? You can configure this screen layout with whatever buttons and features you like. (I believe this is one of the few features that are unlocked when using the software with a Chamsys Wing or DMX ouput device)

 

The Execute window is always available for use whether you've got a wing connected or not, you just can't lock it into full screen mode!

 

Matt

[Wol]

And even without a wing attached, you can get pretty close to the thing being fullscreen. Even more helpful when you have the new execute wing attached, and you get physical buttons to trigger the different features you've programmed rather than using a touchscreen.

 

And I agree with Tomo here, .Net (whichever incantation you might use) just isn't fast enough for the amount of processing you'll want to do on lighting control software. You might get away with it at the start, but as the system expands it gets gloriously slow.

[Dmills]

And I agree with Tomo here, .Net (whichever incantation you might use) just isn't fast enough for the amount of processing you'll want to do on lighting control software. You might get away with it at the start, but as the system expands it gets gloriously slow.

 

Well for medium speed stuff you can emit MSIL instructions directly which lets you implement code generators to produce special purpose code on the fly, and I assume there is a low overhead way to call down into shared libraries written in C (++ optional) for when you need the real speed.

 

Most of the time the real speedups are in picking better algorithms (O ln (n) rather then O n^2 for example) rather then worrying about implementation language (which generally just changes the constant), but the presence of the garbage collector does worry me as IIRC it can introduce unbounded delays.

There are GCs which have bounded response times, but I don't know how easy it is to replace the GC in a .net implementation.

 

While a scripting language is entirely usable for some GUI elements (Who wants to implement a GUI in C? It can be done, but what a pain) I would expect nothing but pain in trying to use one for the number crunching parts. In particular be careful with .Net and multi dimensional arrays, a dereference involves a method call (even of POD types)!

 

One other thing to consider is that there are very highly optimised databases out there, and it may well be that with suitable table design you can actually get better performance by firing off sql queries to a database then you can get by doing brute force things with in process data structures. Of course doing whatever the db does in process will always be fastest, but do you really want to re implement all that?

 

The blue room does its unique take on CS as well as all the other stuff, this place is scary!

 

Regards, Dan.

[mark_s]

Of course doing whatever the db does in process will always be fastest, but do you really want to re implement all that?

 

If you really want to do something that way, libmysqld might be worth a look.

 

Your survey is very flawed though, especially considering it will be part of a final year dissertation! You change arguments halfway through (starting with assuming no such software already exists, even though there are dozens of applications to choose from which do the exact same thing), and end by assuming that such things do actually exist. You need to carefully look at the choices you offer as well. I won't complete the survey myself as I don't consider myself experienced enough to count, but you really need to review it if you don't want to be laughed at when you submit it.

[kev_bite]

As I said before it is only going to be a prototype, so I'm not to fussed that I've written it mostly in C#.Net and to tell the truth it runs really smoothly, it currently runs on 3 different threads and doesn't seem to be as jumpy as software such as FreeStyler which is written in VB6, yes I know VB6 is compiled in P or Native Code and the only kind of threading you have is a Timer which isn't very accurate.

 

Note: In theory, the Timer control's resolution is one millisecond; however, the reality is it's not that good, so you shouldn't use it for time-critical tasks.

(http://articles.techrepublic.com.com/5100-10878_11-5800333.html)

 

All my lectures say that its cheaper to buy more hardware than pay a software engineer to do the same task but create the software that it performs faster. This is true in most businesses they just push it on to higher end hardware.

 

Sorry to everyone who said the questionnaire was limited in responses but it is just a free account on FreeOnlineSurverys so I could quickly collect data. I know the first question was not fully correct but if you look at half the other dissertations in my library at my uni most of them make false assumptions just because most software has already been created before, so really there's not much left to create, only adding features to "current software". which isn't really a good project for final year (so iv been told by my tutor)

 

As to Tomo said about VB.NET isn't powerful enough for a real time control system, I use to work at Howden Kitchens writing software that controlled machines on production lines and they seem to work fine. Also most companies that actually installed the machines actually wrote most of the software in either VB6, VB.NET or Movicon which are really not the fastest software when compiled. but seems to work fine.

(Oh yeah - VB.NET isn't anywhere near powerful enough for a real-time control system. It's more-or-less ok for rapid-prototyping and one-off projects, but the overheads are huge.)

 

Anyway a final thank you for everyone that took the survey. its only online for another 6 days as its a free account!

 

Kev

[Dmills]

All my lectures say that its cheaper to buy more hardware than pay a software engineer to do the same task but create the software that it performs faster. This is true in most businesses they just push it on to higher end hardware.

Which like all such statements, while true needs qualifying, adding more hardware to a system that has locks held for unbounded times will NOT (irrespective of the amount of hardware) make that system realtime capable.

most of them make false assumptions just because most software has already been created before, so really there's not much left to create, only adding features to "current software".

This excuses academic dishonesty? I call bullshit! Use your imagination lad, there is a whole universe of software left to create, even in the show production game there is plenty of opportunity to write interesting new utilities.

As Tomo said about VB.NET isn't powerful enough for a real time control system, I use to work at Howden Kitchens writing software that controlled machines on production lines and they seem to work fine. Also most companies that actually installed the machines actually wrote most of the software in either VB6, VB.NET or Movicon which are really not the fastest software when compiled. but seems to work fine.

Those problems have a strictly bounded size and in that situation even non realtime safe code will work sufficiently well if a fast enough box is thrown at it, this is not the case for a lighting controller where your problem size is bounded only by the time the board op has available to program the thing.

realtime is not about speed, it is about deterministic servicing of deadlines. Now for a lighting controller a somewhat soft definition applies to a lot of it, and in fact none of the user interface really needs to be realtime (it just needs to be fast), but I think you might be unpleasantly surprised by just how subtle the actual number crunching code needs to be to get (for example) smooth slow movement out of a moving light (The time step has to be fairly intimately tied to the DMX frame timing, and the deadline is probably the start of the next frame).

 

Fun stuff.

 

Regards, Dan.

[dosxuk]

most software has already been created before, so really there's not much left to create, only adding features to "current software".

 

There's lots of software still to write, even when you limit it to lighting control software. Admittedly "generic (as in normal not tungsten) lighting control" software is pretty much done, there's lots of places for specific software to be written.

 

As an example, a system I'm looking at building is for control of architectural LEDs, a combination of an LED matrix and simple tools for applying colours and patterns. It would also need to be aware of different areas and treat the seperately, and be able to run sequences, possibly to a real time clock. Outputting over DMX and Artnet is planned.

 

That's just one idea. In my Software Engineering degree, I did a very specialised bit of work, which probably won't be used by anyone anywhere apart from for the specific purpose it was designed (helping us update Flash movies remotely).