Need a Little Help

[samsc]

why you say " by definition HTP merge doesnt work on colour device!"?

I think you have not got something right in your understanding of LTP and HTP?

this is the scenario-
two consoles or devices transmitting continuous information- at the same time-
you know how LTP works? ( last takes precedence ... )

For example-
On console A - transmit channel 1 as say 50 -
On console B - transite channel 1 as 25 -

with LTP data flips between 25 and 50- continuously- this is not very useful - particularily on a colour channel - your colour flips constantly between 2 values- breaking scrollers - or flickering LED products-

With HTP ( highest takes precedence ) output is 50 - data doesnt flip- it stays constant-

How you work with HTP is when you have 2 consoles outputting at the same time - you set the output channels to 0 ( fader down ) when you want the other device to have precedence.

The 0 zero value works as an implicit channel by channel switch between the two data streams-
When you set one controller to 0 values - whatever channels - the other devices channels with any greater value than zero has the output-
you do not have to do any additional switching of devices or configuration-


?

by definition - an HTP merge wont work for a colour device!... an LTP merge would be more usefull on a colour device.
However, as previously stated - a switch function between 2 ports would be of more use as there are 2 controllers connected. .

[Mr_P]

I think you have not got something right in your understanding of LTP and HTP?

I fully understand the difference... a switching method would be better and safer. HTP method relies on the values staying at zero on the other desk... not necessarily guaranteed on an existing show which is what Matt is trying to do... However - if the values do stay at zero - then its a valid method.

[samsc]

what reasons you say then that

by definition - an HTP merge wont work for a colour device!... an LTP merge would be more usefull on a colour device

?

when actually the opposite true- htp merge works - ltp merge doesnt.

it is easy to ensure that values stay at zero- you pull the cue fader down-

LTP would not work under any circumstances - as the outputs fight each other-

it is not feasible in most circumstance to change the configuration of devices - and i would suggest that changing device configuration in any live show - is much less safe than htp priority-
you skip a song for example which might have a config cue - and you have no idea what state the device is in?

htp priority is stateless and easily reversible - changing device configuration is hidden and not easily observed.

and htp priority works on each and every single channel on every universe - and is totally controlled by the lighting console on every single channel- on every universe-

you can only switch entire universes in bulk?
unless there is a super complex per channel priority system somewhere that i dont know about-

I fully understand the difference... a switching method would be better and safer. HTP method relies on the values staying at zero on the other desk... not necessarily guaranteed on an existing show which is what Matt is trying to do... However - if the values do stay at zero - then its a valid method.

[MattMills]

Well, once I get the rig all set up and playing nice, ill try both ways and post the results.

[MattMills]

Oh, I have another quick question. Under Artnet/Universe Map, what should my artnet out be set at? 255.255.255.255?

[samsc]

Oh, I have another quick question. Under Artnet/Universe Map, what should my artnet out be set at? 255.255.255.255?

255.255.255.255 is broadcast address- for all local networks - so data gets to all nodes irrespective of ip address

for a small number of universes this is fine