SCS and DMX

[ckater]

I'm planning to do a lot of stuff using SCS and a light console (ETC Element) to trigger SCS via DMX with the Enttec USB-DMX-Interface, which is suggested.

Unfortunately, we running into some trouble as we tested the setup initially and put the project aside. Since this was in early 2013 and I now have got the time to pick this up, I wanted to ask some questions and give one feature request:

- We had some unspecific trouble with the reliability while using the setup. SCS sometimes didn't respond or was playing more than one cue at one time (so it was triggered more than one time). Do you know, if there some know issues with the setup? Is there anything to keep in mind, while using this? Maybe Drivers, or a newer SCS version (we usually install updates not that often - never touch a running system!).
As the configuration options are limited and the setup is relatively simple, there aren't many options to change. But maybe, the issues is related to my big (and only...) feature request:

- I would like to trigger a cue not through a change of the DMX value (as SCS provides it), but instead of seeing a specific value on a specific channel (maybe, this could be a percent value, but a real DMX value would be better).

Our problem ist, that the system of watching a value change, as SCS using it, could lead to some very annoying problems for the technicians. You always have to keep in mind if the value change could led to uncontrolled triggering in SCS.

Let me give an example: On the light console, CUE 1 has every channel to 0 percent. On CUE 2, the trigger channel goes up to 100 percent, which triggers SCS, threshold is 50. CUE 3 has some light stuff and the triggering channel back to 0. The technician have to keep in mind, that SCS triggers a specific cue every time you pass the threshold, which could led to very annoying effects, if an technician jumps backwards or just back to the default CUE 1 and SCS sees a value change. So, going from CUE 1 to 2 AND going from CUE 3 to 2 is triggering SCS!

It would be very nice, if SCS ist only triggered if a very specified single value is reached. And maybe, you would like keep it extra shure, SCS could be watching this value change only, if it is a positive change (For example, 0 to 1, or 0 to 100, not 1 to 0 or 100 to 0) is seen. This would prevent the technician to accidentally trigger an event by going backwards or going to a default cue or by manual setting all channels to 0.

At all, it would be very nice if SCS has some more options to react to changes of DMX values beside the given options, which are a bit inflexible or potential dangerous for accidentally triggers. I think it should be very easy to implement and a big improvement for all setups where a light console runs SCS directly via DMX.

[Theatre III Sound]

I agree with ckater that the trigger should be a value increasing from zero and should only trigger once until after the value has returned to zero.

I did some experiments with the present implementation and here are my findings:

Let's say I've defined DMX address 25 as the SCS GO button. If the value changes from 0 to 25, a "GO" is triggered. If the value is then increased to 35, another "GO" is triggered. If the value is then decreased to 30, yet another "GO" gets triggered. Furthermore for example, if address 25 going from 0 to 100 in 3 seconds is included in a cue on the light board, many "GO" triggers will happen when the cue is executed as the value increases from 0 to 100 during the 3 seconds. If the following cue has a fade out time, then more triggers will happen as the value goes from 100 to 0 over time. This makes coordinating SCS cues with lighting cues troublesome.

ckater, given the current behavior of SCS, here are some suggestions on making it work better with your ETC Element. Some of the features are only available in the more recent releases of SCS.

First, the SCS help entry "Cue Control Devices - DMX" suggests that only physical buttons (like bump buttons) be used to trigger SCS GO and other commands via DMX. A button typically causes the DMX value to go instantly from 0 to some value and thus would cause only one trigger event when pressed. However, I think you want to trigger SCS cues as a result of executing a lighting cue on the Element. Perhaps you could do that by writing macros and executing them in the relevant cues. A macro could do something like set a channel to full level, wait a short interval (like 100ms) and then set the channel back to 0. When executed, this would produce a sharp pulse in the DMX value and thus trigger SCS in the same manner that a bump button would do.

Second, to give more precise control over the cues in SCS, set up a range of channels (DMX addresses) to control specific cues rather than just a generic Cue GO channel (see the SCS help topic mentioned above for more detail). That way, you could map specific sound cues to specific light cues. This would help you keep the light and sound cues in sync even if the cues are run out of order. I would suggest choosing channels (and DMX addresses) above any mapped to sliders on the Element (say above 400) to avoid accidentally including them in light cues, i.e. only the macros mentioned above would address those channels. Another thought is to connect the ENTTEC USB Pro to the second universe and thus isolate the SCS triggers from the universe controlling the lights.

Beyond using DMX to control SCS, you might consider using MIDI Show Control (MSC) messages instead. The ETC Element can generate MSC messages which SCS could receive. This would require having a MIDI device on the PC running SCS and cabling between it and the Element. Down the road, there may be other solutions, such as Architecture for Control Networks (ACN) which ETC supports.

[Mike Daniell]

A change as you've both suggested is, as you point out, 'easy to implement'.

I see two possible solutions:

1. SCS to only trigger the action if the value changes from zero to any non-zero value.
2. SCS to only trigger the action if the value changes to a defined value, provided that the value was zero at some time since the last triggering of the action (ie as per Bruce's suggestion).

Although (2) is more flexible than (1), is (1) all that is really required?

To implement (1) I would add a checkbox to the DMX Cue Control Properties. The checkbox would be enable this new processing, so leaving the checkbox clear will not affect existing users of DMX control. The new action would not, of course, apply to the 'Master Fader' setting, as that uses the DMX channel value to set the new master level.

[Theatre III Sound]

A change as you've both suggested is, as you point out, 'easy to implement'.

I see two possible solutions:

1. SCS to only trigger the action if the value changes from zero to any non-zero value.
2. SCS to only trigger the action if the value changes to a defined value, provided that the value was zero at some time since the last triggering of the action (ie as per Bruce's suggestion).

Although (2) is more flexible than (1), is (1) all that is really required?

To implement (1) I would add a checkbox to the DMX Cue Control Properties. The checkbox would be enable this new processing, so leaving the checkbox clear will not affect existing users of DMX control. The new action would not, of course, apply to the 'Master Fader' setting, as that uses the DMX channel value to set the new master level.

My vote is for #2, but rather than a user-defined value, trigger on the highest-order bit of the DMX value, i.e. 128H or >50%.

[ckater]

Hmm, yes, Option (1) would be definetitely helpful (because it prevents problems, when a technician is going backwards or to a default cue), but if I'm not mistaken, we didn't solve the problem, that the console fires a lot of commands, if it is doing a fade (which is usually the case). Meaning, the consoles fires a lot of (positive changes) if it increasing the value of a channel from 0 to some other value. Could we prevent this, too? The goal ist to prevent SCS accidentally reading more than one trigger, where in fact, only is one is fired.

[Theatre III Sound]

Hmm, yes, Option (1) would be definetitely helpful (because it prevents problems, when a technician is going backwards or to a default cue), but if I'm not mistaken, we didn't solve the problem, that the console fires a lot of commands, if it is doing a fade (which is usually the case). Meaning, the consoles fires a lot of (positive changes) if it increasing the value of a channel from 0 to some other value. Could we prevent this, too? The goal ist to prevent SCS accidentally reading more than one trigger, where in fact, only is one is fired.

Yes, what Mike is proposing would result in only one trigger event any time the DMX value goes from 0 to some positive value. To get it to trigger again, the DMX value would need to go to 0 to "rearm" and then go positive. The question was whether any value should cause a trigger (like the DMX value going from 0 to 1) or a specific value should cause a trigger (like my suggestion of a change in the highest order bit of the value).

As I indicated in my previous post, you can get SCS to trigger reliably even without the proposed change, but the change would make the trigger mechanism more robust even if the DMX value is changing over time as in a fade. I did an experiment where I could send DMX to the ENTTEC USB Pro to trigger SCS events. I could get it to work reliably if I sent a quick change in the DMX value from 0 to some positive value (in my experiment I sent 100% or 255Hex) and then returned the value to 0 after a short delay (I used 200ms).

However, even with the fix Mike is suggesting, I wouldn't recommend that any DMX address used as an SCS trigger be assigned to a channel that's incorporated into a cue that has a fade time. One way to do this is with a macro as I suggested earlier, but it could also be done with linked cues where the cue containing the trigger has a 0 fade time.

[Boswell]

My vote would be for (2), have the trigger value default to 255hex, but user assignable

[lebem]

Wouldn't profiling the "dimmer" to be either 0% or 100% help with this? Our lighting tech does that all the time for control of things like foggers and other effects bits.

[Theatre III Sound]

Wouldn't profiling the "dimmer" to be either 0% or 100% help with this? Our lighting tech does that all the time for control of things like foggers and other effects bits.

Yep, that would work as well. Forgot about that feature that's available on most desks.

[ckater]

Yep, that would work as well. Forgot about that feature that's available on most desks.

Yes, but sometimes it is a bit complicated (depend on the console and experience) and it wouldn't hurt to have to option on the SCS side.

[ckater]

To sum up the suggested changes (and maybe get them in one of the next versions soon...) would a potential solution this fix?

- We get an option only to trigger a cue if there was a positive change (or maybe, a positive change from 0)
- We get an option or mode to watch for a specific (hex-)value additional to the existing percent-value

I think it is possible to get this changes as additional options which won't affect the default behavior of SCS.

[Mike Daniell]

How about the following options, implemented via 'option buttons' (also called 'radio buttons') under Cue Control Devices - DMX?

• A positive change from any value to a nominated value triggers action
• A change from 0 to any value triggers action
• Any value change (positive or negative) triggers action

The 1st option above would be followed by a field in which you can select the nominated value, which would be defaulted to 255 (100%). By only watching for positive changes, if the DMX values are from a fader that's moved up and then down, then SCS would only trigger the action on the upward movement (assuming that movement reaches or passes the nominated value).

The 3rd option above is the current action implemented in SCS. Although this 3rd option is how SCS currently implements DMX control, I suggest that for new cue files the default should be the 1st option as this is the strongest of the three. Changing this default option I don't think will be an issue for existing users as these option buttons will be very clear in the Cue Control properties.

[ckater]

I think the proposed solution would be a fine set of options which would help in a lot of cases. For us, this is exactly what we need and I would like to see it implemented.

If there aren't any other thoughts oder wishes - how long would it take to implement this?

[Mike Daniell]

Implementing this shouldn't take more than a few days, but I do have to fit this in with other priorities. Currently I'm working on enhancements to Live Inputs, which I personally need for a production in January! There are also some other enhancements such as tempo control that I'm planning to implement in the next release. When do you 'need' the DMX changes?

[ckater]

Unfortunately, my next (big) production is also in January, starting on the 7th and it would be very useful to have it until then, because we are doying some time critical stuff, where light and sound should have to be synced very accurate.