Programming moving lights

[Shez]

I’m interested in hearing about people’s approach to programming moving lights. Big topic, yes, and somewhat dependent on their desk of choice but I’m sure there must be some methodologies and techniques that are common across the board.

 

Let me give you an example of what I mean: Say a director says, “I’d like that fixture to move in an arc from that point on stage to that point over there, starting in open white but cross-fading to red by the time it reaches this point in the middle, accelerating towards the end and snapping to blackout as soon as it reaches the end of its travel. Five seconds from start to end. Then those other three fixtures are to perform that same movement (same start and end marks on the stage) one by one, one after the other.” How would you go about breaking that lot down in to a form that can be programmed? Presumably palettes for the start and end positions, a fan of some kind to stagger the moves across the fixtures? What else? (I'm in the process of learning MagicQ at the moment so I'm familiar with the terminology that that uses but possibly less so with a GrandMA for example.)

 

I’m just interested in the thought process involved when programming more complex movements where different attribute changes take different lengths of time or start / finish whilst other changes are still happening. Do you program it all in one go? Or do just the movements first and then add in the colour / intensity changes?

 

I’m looking to buy a book on the subject too – the two that seem to be recommended a lot are

http://images-eu.amazon.com/images/P/0240806026.01.MZZZZZZZ.jpg and http://images-eu.amazon.com/images/P/0240812220.01.MZZZZZZZ.jpg.

Can anyone comment on whether one is better than the other in explaining this kind of thing?

[mac.calder]

I like to program the entire sequence step by step including all gobo, colour, position and focus parameters - generally without timing. Then I work on timing.

 

The described effect could be programmed a number of ways depending on the timing - it could be done in as few as 2 cues or 10+ cues.

[Ynot]

Many desks will have a follow/hang/delay/pause/step whatever option - our Ion does, certainly, and the Strand 300/500 did, but not quite as simple to get to grips with.

 

I like the way Ion/Eos can do things like this, and if you're looking at a set of lanterns doing similar things, you can use the effects engine to good effect in conjunction with follow/hang.

 

 

[indyld]

In the interests of simplicity, I will just say that there must be as many ways to program moving lights as there are programmers. The workflow often depends on a number of factors, the show, the time, the desk and also the desk that the programmer used to use before they got "this" one.

 

For the example above, there are a number of ways that I would approach it, again, depending on many of the above parameters, probably the largest being the desk capabilities and how I plan to play the cue back.

 

The books shown above are both good works. Cadena's is quite technical and historical on systems and fixtures, whereas Schiller's is very much about how he works (well, worked really as controls have evolved since then). Some of the basic concepts are transferrable, Schiller's approach is very much based in what he was doing at the time and using particular desk capabilities which nonetheless doesn't detract from the content. Some of the detail has been superseded by desk functionality and new-fangled abilities to do stuff without having to work out complex steps of things and let tracking create visual magic. This is particularly true of FX programming.

 

But there are some examples / exercises that Schiller can teach us, based on some ol' time programming tricks that can be useful to explain concepts still in use today. Schiller's diary is interesting from a historical perspective (and nostlagia, if you were a Hog II programmer back then) Cadena's book is less about programming.

 

In the fast moving (ahem) world of moving lights and control, both books are a good read but date quickly.

 

E2A: In an old fart way, I think that certain effects from "back in the day" were much better, and the programmers too, than the modern functionality that allows an 8 year old to rock up to a desk and get a Mexican Wave out of it. I urge people to learn all you can about programming from the "old days", before getting constrained by "easy" FX generators. You can then create any look or transition you can think of.

[paulears]

I found the Schiller book the most interesting because he's based it on how he works. The problem is that as indyld says, there are so many ways to programme. I've been using desks with conventional subs for years and it's only been a year or so since I realised that they can be used so differently on modern desks. Another topic today mentioned the concept of putting a range of colours on a cues stack, with another having perhaps positions or effects. This is a radical change to somebody who grew up on controls that did not work this way. The two books mentioned both assume the reader is familiar with these different approaches. The first time I read the Schiller book, much seemed confusing and I only skimmed the second half. However, now I've discovered the more rock and roll style of programming, going back and reading again, it makes more sense.

[indyld]

... Another topic today mentioned the concept of putting a range of colours on a cues stack, with another having perhaps positions or effects. This is a radical change to somebody who grew up on controls that did not work this way...

 

Using stacks like this is what I often refer to as the Hog II way, as it became popular with certain styles of busking programming on the console when the Hog was the default "general public" desk that went everywhere rather than more "proprietory" ML desks. "Hey, can you run a Hog?" was the question from the production managers when they called up. Having fewer playbacks than a Sapphire or something, meant stacking things up a bit to minimise page changing.

 

People that come from an Avo background think one way, Hog another and the theatre peeps (Yuck, 500s and latterly ETCs) another way, and this informs how they do things. The MA and the MagicQ take bits from everything and make everything possible in about 5 different ways.

 

Theatre style programming is very one dimensional because of the nature of playback required and this is why I personally hate the workflow of those theatre desks for moving lights, even though the Strand stuff was the default for generics and theatre cue stacks. Of course, Rob Halliday would disagree although he does have a keen interest in the development of other controls too and is always up for discussion on such topics.

 

Other styles are more 3D (in terms of programming and playback not where the movers are).

 

E2A: This kind of programming "problem" is best dealt with in steps, almost imagining a timeline where each point in time or change is a different step but not all attributes are in all steps, stacked up like tracks in iMovie or something (Jands Vista users say Way- Ohh). One thing to consider is that moving from here to there COULD be two pan positions, and creating the arc could be two tilt positions BUT it depends on the orientation of the fixtures to the proposed points on stage.

 

To replay this again and again, ol' theatre stack thought processes are probably the best starting point. If you get into wait/delay times is up to you, without them it's still possible with straight follow ons. Just depends on the actual timing and how many cues, as said above. The best thing about modern desks is the ability to fan/offset times over fixtures easily and not faff about with wait calcs.

[Young Johnstone]

What console do you use / understand the most?

It may help as we can give you a bit more specific advice! I can think of three different consoles that I use a lot, and each way I'd probably program in a different style!

 

When I program ML's I'm always thinking ahead! What's this fixture going to do next? That way it all kind of slots into my head as to what I'm going to do and how I should program it! Theres nothing more annoying than sloppy programming where lights spin a full 360 to get to the next position while the colour wheel whizzes round!.

[Shez]

What console do you use / understand the most?

I've not done all that much in the way of ML programming (hence the question) but it's mostly been a Pearl I've used before for that. However, MagicQ is what I'm concentrating on learning at the moment - the standalone visualiser with the "awards" show that they supply has been extremely useful for trying things out.

[themadhippy]

, MagicQ is what I'm concentrating on learning at the moment - the standalone visualiser with the "awards" show that they supply has been extremely useful for trying things out.

the freebie student version of capture works very nicley with magicq

[Shez]

the freebie student version of capture works very nicley with magicq

Ooh now that looks tasty. I'm also eagerly awaiting MagicQ's own visualiser which is due fairly imminently. Yet more software to learn...

[greenalien]

The difficulty with the scenario that you suggest is that it requires the fixture to have red next to open white on its colour wheel - if it doesn't, then there's going to be a problem, unless you fade it out, change colour, then fade it back - or fade between 2 fixtures.

[Shez]

I was thinking of a fixture with colour mixing rather than just a wheel. Not that it matters particularly here - pick any continuously variable attribute instead - zoom, iris etc.

[scjb]

OP, have you looked at the back issues of PLSN? Brad Schiller has a regular column called "Feedng the Machines" which is dedicated to programming techniques and relevant thought processes. Back issues are available as PDF from their website.

[Shez]

That's not a publication I was aware of; thanks Stephen, I'll have a dig through their archive.