Jump to content

house light control from show lighting system LTP or HTP


gus_b

Recommended Posts

The current system design in a venue has an architectural dimming system for the house lights with a DMX512-to- system’s proprietary protocol mux.

 

In standard cases where the show lighting console would want to take control of the house lights (either as part of a cue or on a handle) would this usually use HTLP or LTP merging?

Link to comment
Share on other sites

Generally, all channels that control a dimmer are HTP :o

I don't think that was the question.

 

I'm not sure about standard cases, but presumably an LTP merge is advantageous since it allows blackout control from the lighting console from any state. With HTP you would need both control systems to be set to zero for a blackout. Neither prevents override in emergency so this should not be a concern.

 

And, in response to the comment that all dimmer control channels are HTP, I deliberately control houselights with LTP :huh:

Link to comment
Share on other sites

In general, HTP control is better for houselights because it is easier to understand.

 

I've done a lot of installations where various on-paper 'Better' solutions were initially installed, only to be reconfigured into HTP control after a few weeks/months because it was too complicated.

 

HTP control is both simple and obvious - you can explain it to anyone.

 

LTP control is neither - for multiple separate controllers it's essentially impossible anyway, because the end result of two simultaneous fades is unknown. (Who moved last?)

Link to comment
Share on other sites

Surely though if you are talking about multiple panels (SM desk, control booth, FOH) and an lx desk, LTP makes it far SIMPLER. In other words you can go to a blackout from any panel or the desk, whereas in HTP if one panel has been left at say 30%, no other panel would be able to take the level below that?
Link to comment
Share on other sites

Surely though if you are talking about multiple panels (SM desk, control booth, FOH) and an lx desk, LTP makes it far SIMPLER. In other words you can go to a blackout from any panel or the desk, whereas in HTP if one panel has been left at say 30%, no other panel would be able to take the level below that?

Whereas on the other hand, if you wanted to bring them up in case of an issue, an LTP merge may not allow you to do this from any single point.

Link to comment
Share on other sites

Actually, having thought about it there are a couple of fundamental problems with LTP:

 

Firstly there is a good chance that levels will end up snapping unless you are very careful/lucky/or the proprietary system has automatic fading.

 

Secondly the control desk will not send out any value unless there was an explicit change in level. So it is quite conceivable that if the last houselight command from the desk was value zero and remotely they have since been set to full, firing a 'house off' cue will have no effect.

 

So I change my mind, although I will always use LTP control locally for this.

Link to comment
Share on other sites

Exactly. That's what always scares me when people say they want an LTP merge...

 

Within a single unified controller, LTP is easy and very often perfect for the application, but between disparate control systems it becomes essentially impossible.

 

For example:

You have an architectural control system with many button stations around the venue. LTP within that control system is great - press any button anywhere and you fade to the new state.

- The system can easily know which button was most recently pressed, so the system works perfectly.

 

You have a lighting console (maybe with multiple facepanels/processors all working together) with many direct action buttons and/or faders. You move a fader/press a button and the lights do the relevant 'thing'.

- Again, the console can easily know which fader was most recently moved etc, and thus it works perfectly. It can choose to do level matching with faders or do good fades from 'current' to 'taregt' values that are appropriate to the items being controlled.

 

But when you attempt to merge the two controllers - who's in charge?

The 'merger' cannot know which controller had the most recent 'user action' - all it sees are changing values.

 

So what happens if the lighting console (A) executes an 'upfade' while the architectural system (B) executes a downfade?

 

On each packet reception, each gives a different value to the previous one from that system.

By definition, one packet will arrive before the other, even if only by a nanosecond.

So if both are sending at precisely the same rate, 10% change each packet, you'll get the following output:

Start values:

A:0

B:100

Output: 100

 

Output during the fade:

100, 90, 10, 80, 20, 70, 30, 60, 40, 50, 50, 40, 60, 30, 70, 20, 80, 10, 90, 100, 0

 

Whether you finish at Full or Zero depends entirely one which final step in the two fades is the last to be processed.

- This isn't even necessarily the last change to be sent!

 

There are ways to avoid this kind of flicker (like 'level matching' control that's often done with LTP faders on lighting consoles), but the output will always be at the 'whim' of the merger, because a user can never know who sent the last change - and the controllers can never know what the merge result currently is.

(In many network protocols the controllers could know what the others are outputting, but that doesn't tell them what the current, real output is.)

 

The sACN and ETCNet2 protocols use the much more predictable idea of Priority - one source is 'more important' than the others, and sources can modify their priority when they become more or less important.

- For example "Take Control" or "Give Up Control" buttons on the architectural system.

(Sources at the same level of Priority are merged HTP)

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.