[In 11.7.0] Lighting Cues in different Venues

[tocsin]

Hello and good evening,

if i want to use lighting cues in one show and this show is playing in many different venues... so i have to reprogram every single lighting cue every time i am in a new venue, because the dimmer adresses of the lights are never the same. it would be helpfull if the lighting cues are fixture related and the dmx adresse setting is done in a seperate setup menu. is this possible in the future?

i am asking because i am using lighting software like DMX Control or PC_Dimmer wich have this feature and this is a real time saver. Just setting up the DMX adresse of all the fixtures and the lights are running.

thanks
tocsin

[Mike Daniell]

I'll certainly consider this for the next release (after 11.6.1). What info should be recorded for each fixture? I presume that under Production Properties (which is constant for all venues) there should be a list of fixtures with at least the following properties: 'Description' and 'Number of DMX channels used by the fixture'. Then in the Device Map (which can vary between venues) we should set the 'DMX Device' and 'Initial DMX channel' for each fixture.

Does that seem reasonable? Are there any other properties that should be included?

[Edi_28]

+1 from me.

Your suggestion absolutely seem's reasonable, Mike!

One thing would be to define the fixture itself (Name, Fixture related named DMX adresses)
For example:
- RGB LED PAR 1
- DMX 1 = RED
- DMX 2 = GREEN
- DMX 3 = BLUE
- DMX 4 = DIMMER
- DMX 5 =...

- RGB LED PAR 2
- DMX 1 = RED
- DMX 2 =... (can be exactly the same as for RGB LED PAR 1)

Then there must be a possibility to specify the fixtures DMX start address which can vary between the venues.
For example:
- RGB LED PAR 1 = DMX21
- RGB LED PAR 2 = DMX29

In ligthing cues you no more enter a list of DMX addresses. You select fixtures and can set values for the fixtures (fixture related) DMX addresses.
Those values are translated to the real (venue related) DMX addresses with DMXext = DMXstart + (DMXfixture - 1).

I could imagine the lighting cue would look as a list in a list. The outer list is the fixture, whereas the inner list are the fixture parameters.
So it is much easier to define lighting cues as you work with named fixtures and named fixture parameters instead anonymous DMX addresses.

Another great thing would be if you could define if a fixtures DMX parameter is fadeable. So the production default fade time is only applied on DMX addresses which should be faded (I know this can be avoided with the "f" parameter -> 152@100f0).
The "fadeable" checkbox can be already specified when the fixtures are specified, but should be able to overwrite in the lighting cue where the fixture is used.

The "fade out others" should also be aware of the "fadeable" checkbox! So when another RGB light is started by a lighting cue, only the DIMMER address of the currently RGB light should be faded and not the COLOR addresses! This would also meet my feature request of the need to exclude specific DMX addresses from fading (Light fade out stops DMX operated curtain movement).

I hope this was understandable

By the way... The existing features of SCS are absolutely great! Just dreaming of a little bit more...

[Mike Daniell]

Looks good. Thanks for the suggestions. We probably also need a list of 'Fixture Types', perhaps held in a separate library available for all productions. A Fixture Type could be:

- RGB LED PAR CAN
- DMX 1 = RED
- DMX 2 = GREEN
- DMX 3 = BLUE
- DMX 4 = DIMMER
- DMX 5 =...

Then for a specific production you can select:
- RGB LED PAR 1: Type RGB LED PAR CAN
- RGB LED PAR 2: Type RGB LED PAR CAN

and in the device map for the production you specify the starting DMX address for each fixture (eg for RGB LED PAR 1 and RGB LED PAR 2).

There is, however, an issue in holding fixture types in a separate library that's not dependent on a specific production. If you change the name of a fixture type (which may well occur when you add new types of light to a venue) then any existing cue files that refer to that old fixture type will lose that connection.

[Edi_28]

I like the idea with the separate fixture library like most lighting consoles have one.
Each fixture has a start address and different attributes (dimmer, color, gobo, x-movement, y-movement, etc..) which also have an "sub-address" to the Start address. All the attributes can be a predefined enumeration list, so the software knows, that for a color attribute three addresses (R,G,B) are needed and so on...
There should also be the possibility to define "user attributes" with a user definable list of options, where each option has a DMX value (e.g. Attribute "Effects" has internal DMX channel 8 and the user defined options are "Constant color" = DMX value 25, "Fade Out Effect" = DMX value 35, "Fade In Effect" = DMX value 70, etc...)

So when programming a lighting cue you could only work against named fixtures and attributes and the values are translated against the correct DMX address of the fixtures attribute (e.g. Color "Violett" = 100% DMX Address "Red" + 100% DMX address "Blue" - could think of a color picker in the lighting cue )

This would give you the maximum flexibility and support when programming lighting cues.
And don't forget that not all attributes (DMX sub addresses) must be included in the "Fade Out Others" thing.

Can suggest to have a look at lighting software "freestyler" (Freeware) to get an idea how fixtures and attributes are defined there. I know that SCS is much more than a lighting control software, but having some tools (color picker, coordinate picker, gobo selector, etc.) to define Dmx address values more easily would be more than great!

[Mike Daniell]

As from SCS 11.7.0, fixtures are supported, but not 'fixture types'. In this version, the DMX start channel of each fixture is held in the device map so different start channels can be assigned for different venues. The lighting cues themselves, therefore, do not directly refer to specific DMX channels. This provides for 'soft patching' of DMX channels. Supporting 'fixture types' has not been implemented due to the significant need to access or maintain multiple libraries for numerous brands of fixture.