Some Last Minute Opinion Gathering

[TomG]

If you could take a moment to briefly answer the four questions below, these questions form part of my research pack looking into how visual programming can affect how a show is plot and how speed could potentially be increased, similar to how digital video editing has evolved. Please keep your answers short as I will only be picking quotes from this thread, to support other secondary and hands on research.

 

Question 1: Why hasn't visual and timeline editing been integrated into current lighting desks?

 

Question 2: Can the speed improvements, that were seen when non-linear timeline editing was introduced to video, be replicated with lighting, especially with large complicated lighting plots?

 

Question 3: Will an easy visual (timeline) interface remove the need for specialist programmers and/or the use of multiple desks to provide the complex effects seen on many current shows?

 

Question 4: Can visual editing simplify the synchronisation of lighting to audio and other effects, for example at a fireworks display, lighting and fireworks need to be timed tothe audio accurately to achieve the desired effect?

 

Many Thanks,

Tom

Ps, I know about Jands Vista and its current integration of a timeline editor...

EDIT: Sorted out the dodgy formatting after a copy and paste from word.

[Joe Bleasdale]

Is this for the sake of knowing or for a specific project...?

 

But anyway the only other desk iv use with a timeline is vector. The timeline is an "object" much like a group or a cue and all it is, is a series of "events" macro triggers, cuelist triggers, schedule/calendar commands etc. Its not really like the vista where you can edit fixture times and stuff within the command line.

 

Where I see the timeline powerful currently is in timecode shows/fixed installs that run 3 shows a day always exactly the same. Could it be the future? Possibly it all depends on speed, reliability and preference.

 

The vista is a great desk - astoundingly fast but I don't think myself personally would be able to go between that and a normal command driven/touchscreen pool desk without seeing some lag in me performance time because of the differences between the two. When I saw some of the stuff It can do though - wow any programmer would probably be impressed.

 

I see timelines useful also for small/medium size shows but large or huge ones - I don't know... We shall see I guess!

 

Thanks.

[TomG]

Thanks for the quick reply, It is for a research project, for uni, but also out of general interest I'm interested to see why this hasn't really been done before in a way that is similar to video and if it has, I haven't really looked hard enough.

 

Thanks for the information about the vector, I hadn't thought about it as an object, but more in the sense of cues (similar to video clips) being brought together in a timeline with fades, overlaps and timing all being dealt with by the timeline.

 

Regards,

Tom

[Joe Bleasdale]

With the timeline there is an extra type of time called "event time" which is separate to that of the cues and discrete timing within a cue. Just to make things a little more complex! A timeline can be viewed almost like a cuelist - in cell form or graphical form, the latter being the thing your thinking of.

 

Your not just limited to 1 either because it's an object you can have hundreds of them. In the workspace tree you can open a "pool" or "directory" in softey mode showing them much like a palette or group. I use Context display when I program the desk which makes going between multiple object types within the same screen a breeze, don't need to setup tabs or workspaces, just have context open and anything object wise you put into the command line - it will show on the soft keys. Off topic slightly sorry but I think very related to speed!

 

Thanks.

[Tomo]

1) It has been tried a few times, but it has never become popular.

 

Timeline works for audio & video because A/V is essentially a long tape that you cut, splice and copy. (Whether virtually or not)

You don't edit the sources themselves, instead you cut, copy and paste sections of them around to create the final result.

- If the camera was in the wrong place, tough.

 

Lighting is essentially the same as moving those cameras and actors around in the first place. (This may be why move-fade consoles are so popular for theatre, it matches what the director does on stage.)

 

Show Control has however used timelines for decades.

 

Essentially, timelines are for editing time.

- It's a good way to select which of your available "events" or "clips" to trigger and when.

They don't allow you to edit or create the events themselves - you must use a different kind of editor for this.

 

2) Almost certainly not.

In lighting, you are directly editing the actual elements of the sources.

 

Even in a fairly small production there will often be hundreds or even thousands of elements that need to be adjusted, and very few of those adjustments are time-based. The majority of edits are things like "Turn on", "Be red", "Point at the drummer".

 

Secondly, lighting is usually 'live', while video editing is always 'pre-recorded'.

- Even is a very long-running theatrical productions an actor might miss lines, be faster or slower, or have to wait more or less time for the audience to catch up.

 

3) Definitely not.

There are many skilled (and well paid) Avid operators.

 

I do not think that timelines have any implications in either direction for the number of consoles and programmers used on a given show.

 

Multiple consoles are already unnecessary for the majority of productions.

This is primarily because modern consoles do a better job of 'abstracting and simplifying' the specifics of how each luminaire works, allowing a single programmer to manage more individual luminaires.

 

However, some newer luminaire classes (eg media servers) have so many elements that they often require a dedicated programmer.

 

4) Most Firework-sync systems are already using timelines in a Show Controller.

However, in this case the lighting is a number of pre-recorded 'events' once it's exposed to the timeline.

[TomG]

Thanks for the replies :) both have been very useful, to both show a need for visual editing, and also why it isn't such a good idea :)

 

I come from and Avo background, with a slice of Strand, so bits of visual editing are already included in avo, for example the pixle mapper and shapes, other than that it is still a very command / event driven process.

 

Regards,

Tom Glover

 

<snip>

 

Even in a fairly small production there will often be hundreds or even thousands of elements that need to be adjusted, and very few of those adjustments are time-based. The majority of edits are things like "Turn on", "Be red", "Point at the drummer".

 

Secondly, lighting is usually 'live', while video editing is always 'pre-recorded'.

- Even is a very long-running theatrical productions an actor might miss lines, be faster or slower, or have to wait more or less time for the audience to catch up.

<snip>

 

I've just had a thought about how this could be implemented whilst still keeping the live element and the traditional "Go" button.

 

Just as is currently done times are edited in a spreadsheet or command line for cue transitions. This could still apply with timelines, as the timeline could look at the few attributes to be times and the transition between two cue's only, it doesn't need to know how long the cue is.

 

Thats just a way I could see it working in a live environment, if it get implemented again is another matter.

[indyld]

Re multiple desks:

 

There are reasons for using "multiple desks" that extend beyond the creative capabilities or ease of use of one console or editing system: timeline or any other. Now, with networking, the point of a number of workstations is often simply multiple operators and no longer the technical limitations in output of each console as it used to be.

 

Using multiple operators greatly increases the computing power and multi-threading capabilities of the system as a whole (I'm talking the human brain here) as however big your processing is, or how great your editing system is, the pinch point is the single human doing it. Humans are hugely powerful and very cheap computing power in the scheme of things. Now the difference is that the show can be finally played back from the master show file when the brainpower is done with.

 

Of course, the easier the interface becomes,the expectations and system complexity ramp up, and the more important the specialist programming humans become. This leaves a kind of equilibrium in the equation, I suspect.

[Brian]

I'm not sure the comparison with NLE video systems is quite right (and I speak as someone involved in NLE video for over 20 years).

 

Video NLE has the following characteristics...

 

The end product is a real-time, time-constrained stream. There is no pause or skip button.

The end product is made up of multiple layers.

At any one time only a very small number of those layers appear in the final output.

Each layer is also a real-time and time constrained stream.

Each layer is the same length as the final product. (non-intuitive but trust me, it is)

The generation of the final stream does not need to happen in real time. Rendering is/was very common.

 

The edit process involves moving layers relative to each other in time and deciding how and when to transition between them.

 

 

When you move to big budget movies the NLE paradigm changes as you now have dailies to consider. If the shot you want doesn't exist it's often possible to re-shoot that section allowing you to change your source content.

 

 

Lighting on the other hand is all about 'static' states chosen from a pool and the transitions between them. I say 'static' because in my mind a 'static' state might be something like a running Ballyhoo. The final output can comprise multiple separate states all visible at the same time. In reality there are also relatively few different states in the pool.

 

 

 

 

There is, I believe, an interesting unexplored paradigm for lighting using layers. But that's for another day.

[TomG]

Thanks all for the responses :)

 

The report is now submitted, but this topic has raised some interesting points, many of which I hadn't thought about before today.

[Brian]

The report is now submitted...

Nothing like leaving it until the last minute to do your research!!! :** laughs out loud **:

[indyld]

There is, I believe, an interesting unexplored paradigm for lighting using layers. But that's for another day.

 

Well, as the report is now submitted then it can be considered another day ;)

 

I believe that many LD/Programmers have been using layers in their daily life, but not so much in cues and transitions like a theatre stack.

 

The very old Light Jock trick of creating different movement shapes by creating a vari-speed pan sine and another tilt sine on different playbacks is a case in point. Each could be considered a layer that has it's time alignment shifted relationally, creating a circle or an ellipse or what have you. Perhaps that not by Brian means by the layer paradigm, but essentially you are laying things on top of each and they are interacting - and you can adjust that interaction live.

 

Currently, however, there is no real layer stack order.

 

Tell us more...

[TomG]

The report is now submitted...

Nothing like leaving it until the last minute to do your research!!! :** laughs out loud **:

 

Considering its in a degree / course I'm not interested in, the soon I get out of there the better :) Its gone down hill vastly over the last year or so, the reputation of the uni is in free fall, and courses are being cut left right an centre, I'm not completing my third year because of all this...

 

It all over now :)

[paulears]

I've come to this after the train has left, but I re-read a bit and suddenly thought about the mentions of video NLE - as Brian and other said, a few tracks on a edit screen sort of work - but what is being talked about is more like After Effects, where you have lots of horizontal tracks all doing one parameter, which is much like movers with attributes. Dealing with just a couple of dozen of these is troublesome. Sure you can use a razorblade tool and shift things around, but it's so easy to generate 'orphans' little bits of activity that get lost when being manipulated and it takes a long time to sort out because even on big screens, you cannot see them all! It can produce very clever results, but simple, easy and quick it is not! I can't see how it would work any better for lights. Easy for simple stuff, but too complex for the difficult stuff!

[Brian]

Its gone down hill vastly over the last year or so, the reputation of the uni is in free fall, ...

Is that the uni and courses mentioned in your sig?

 

That's a real shame. I used to employ lots of people who came into industry through that route.

[TomG]

Its gone down hill vastly over the last year or so, the reputation of the uni is in free fall, ...

Is that the uni and courses mentioned in your sig?

 

That's a real shame. I used to employ lots of people who came into industry through that route.

 

It is the uni mentioned in my signature, but the course is still ok :) it's the sister courses, there cancelation, and the lack of funding in general is bringing the reputation and teaching levels down. The new Studio / building is not fit for purpose, and on top of that very restricted access to those resources, due to external companies having priority over students.

 

It is certainly not worth the 9k a year that is now charged...