Q Light Controller+

Posted: **Mon Apr 27, 2020 9:05 am**

Currently there is a well defined list of presets available for controlling gobos. Unfortunately, about half of the fixture files use the old custom definition instead of the presets. We would like to update the fixture library to use the defined presets "GoboMacro" and "GoboShakeMacro".

Before beginning on this we have a question. In most gobo groups there is one preset where no gobo is put in front of the light source (often called "Open") just like ShutterOpen in Shutter groups. This preset is implemented in different ways across the fixture definition files. Here are some examples

Code: Select all

<Capability Min="0" Max="0">Open</Capability>

Code: Select all

<Capability Min="0" Max="9" Res="Others/open.svg">Open</Capability>

Code: Select all

<Capability Min="0" Max="7" Preset="GoboMacro" Res1="Others/open.svg">Open</Capability>

Our question is: How should "Open" or "No Gobo" be defined?

Option 1: <Capability Min="0" Max="7" Preset="GoboMacro" Res1="Others/open.svg">Open</Capability>
Option 2: We add a GoboOpenMacro (or "NoGoboMacro") preset and use <Capability Min="0" Max="7" Preset="GoboOpenMacro" Res1="Others/open.svg">Open</Capability> (in this option do we need Res1 or should Res1 always be "Others/open.svg"?)

Our preference is for Option 2. Option 2 clearly distinguishes between gobos that change the fixtures output (GoboMacro and GoboShakeMacro) and gobos that do nothing to the output (GoboOpenMacro). Implementing Option 2 makes it straightforward to add a Clear or Locate button that puts all gobo wheels to GoboOpenMacro with one click.

Looking forward to hearing your feedback,
Ray Console Team

Posted: **Wed Apr 29, 2020 6:56 am**

Are there any comments? If not we will prepare the changes in line with Option 2 for review on Github.

Posted: **Wed Apr 29, 2020 8:47 am**

Option 1 is correct.
Again, QLC+ 5 preview tries to simulate as much as possible what happens in the real world.
Open gobo is actually a gobo. A hole in the gobo wheel that let all light to pass through. Open gobo (open.svg) does exactly that, so please leave it there.

Posted: **Wed Apr 29, 2020 1:31 pm**

OK. Thanks for the clear explanation. We have a follow on question:

What is the correct approach for effects channels in Gobo groups. For example in Chauvet\Chauvet-Intimidator-Beam-LED-350.qxf

Code: Select all

<Capability Min="120" Max="127" Preset="GoboMacro" Res1="Others/open.svg">Open</Capability>
<Capability Min="128" Max="191" Preset="GoboMacro" Res1="Others/open.svg">Cycle effect with increasing speed</Capability>
<Capability Min="192" Max="255" Preset="GoboMacro" Res1="Others/open.svg">Reverse cycle effect with increasing speed</Capability>

From your comment, my assumption would be that the correct use of presets would be:

Code: Select all

<Capability Min="120" Max="127" Preset="GoboMacro" Res1="Others/open.svg">Open</Capability>
<Capability Min="128" Max="191" Preset="RotationClockwiseSlowToFast">Cycle effect with increasing speed</Capability>
<Capability Min="192" Max="255" Preset="RotationCounterClockwiseSlowToFast">Reverse cycle effect with increasing speed</Capability>

Or is there a better approach to this situation?
Kind regards
Ray Console Team.

Posted: **Wed Apr 29, 2020 3:00 pm**

Your assumption is correct.
In fatc, presets are not strictly related to a channel type.
Rotation can be applied to color wheels or gobo wheels. QLC+ can behave correctly with the 2 information combined

Posted: **Tue May 05, 2020 12:59 pm**

Thank you for your answer. We have a further question concerning Gobo groups. The Gobo group is used in 4 different situations:

1. To represent a channel controlling a gobo wheel with static gobos
2. To represent a channel controlling a gobo wheel with rotating gobos
3. To represent a channel controlling the speed of rotation for a previous channel's rotating gobos
4. To represent a channel controlling the fine position of a gobo wheel

An example of this is Clay-Paky-Alpha-Spot-575-HPE.qxf

Our question is: how is the relationship between situations 1. or 2. and 3. or 4. managed in QXF? How does QLC+ know that for a specific channel with rotating gobos, that there is a channel where the speed and direction of rotation is set. This will be needed so that the simulation on QLC+ of the fixtures output shows the output as seen in reality.

Posted: **Mon May 18, 2020 2:37 pm**

Any thoughts on the question posted on 5th May?

Posted: **Tue May 19, 2020 6:32 am**

#4 is easy: i'ts the combination of control byte (LSB) + gobo channel type

#1 and #2 right now there's no difference. There's GoboMacro and GoboShakeMacro. We should add GoboRotatingMacro so that #3 makes it clear what should rotate

Posted: **Thu May 28, 2020 11:46 am**

Thank you for your reply. Yes, a GoboRotatingMacro is essential to differentiate between rotating and not rotating gobos.

However we still have the problem of the control software not knowing which rotation channel (#3) affects which gobo channel (#2) or which gobo LSB channel (#4) affects which MSB channel (#2). This is needed when there are multiple rotation channels (#3) and multiple LSB channels (#4) as in the Clay-Paky-Alpha-Spot-575-HPE.qxf fixture attached above.

Our proposal is:

1. Every channel is assigned an variable: Index
2. Channels can have one or more values: AffectedChannel with variable Index
3. Add a dropdown to the Fixture Definition Editor in Edit Channel called "Affected Channel" with a list of all group indexes in the fixture definition.

This solution does not break any existing functionality. It will also be useful for devices with multiple PositionTiltFine presets or other LSB presets. Important is that the Index is not change if a channel is moved in the list or deleted. A full file is attached and here are some examples:

Code: Select all

<Channel Name="Tilt fine" Preset="PositionTiltFine"/>

becomes

Code: Select all

<Channel Name="Tilt fine" Index="10" Preset="PositionTiltFine">
  <AffectedChannel Index="9"></AffectedChannel>
</Channel>

OR

Code: Select all

<Channel Name="Gobo 1 rotation">
  <Group Byte="0">Gobo</Group>
  <Capability Min="0" Max="127">Fixed position</Capability>
  <Capability Min="128" Max="190">Fast to slow rotation</Capability>
  <Capability Min="191" Max="192">Stop rotation</Capability>
  <Capability Min="193" Max="255">Slow to fast rotation</Capability>
</Channel>

becomes

Code: Select all

<Channel Name="Gobo 1 rotation" Index="19">
  <Group Byte="0">Gobo</Group>
  <AffectedChannel Index="18"></AffectedChannel>
  <Capability Min="0" Max="127">Fixed position</Capability>
  <Capability Min="128" Max="190">Fast to slow rotation</Capability>
  <Capability Min="191" Max="192">Stop rotation</Capability>
  <Capability Min="193" Max="255">Slow to fast rotation</Capability>
</Channel>

It is also possible to have multiple affected channels:

Code: Select all

<Channel Name="Pan - Tilt time" Index="13">
  <Group Byte="0">Effect</Group>
  <AffectedChannel Index="7"></AffectedChannel>
  <AffectedChannel Index="9"></AffectedChannel>
  <Capability Min="0" Max="0">Full</Capability>
  <Capability Min="1" Max="254">0.2s - 310s</Capability>
  <Capability Min="255" Max="255">Follow data cue</Capability>
 </Channel>

This would take a lot of effort to implement. We would:

1. Update the Fixture Definition Editor
2. Update the QXF schema
3. Add the Index variable to all fixturs in the library
4. Add the AffectedChannel values to gobo rotation channels (#3) only

Are there any concerns about us implementing this change?
Kind regards

Posted: **Thu May 28, 2020 3:10 pm**

To be honest I don't like the idea. Too many changes for a too niche feature.
I need some time to think about it.

[EDIT] first thought. We need to avoid #3. Channels are already indexed in modes. We just need to add a way to set an "affect" property.

Posted: **Mon Jun 01, 2020 2:55 pm**

In our opinion having an index for each channel is a more stable approach. This is because dependencies elsewhere in the fixture definition do not need to be updated if a channel is moved, removed, or added. On the other hand we understand the need to keep the QXF format as simple as possible.

It would be possible to base the AffectedChannel simply on the order of the channel, as is done in Modes. We would need to add some functionality to the Fixture Definition Editor for the situation when a channel is removed. Here is an example of the proposed solution:

Code: Select all

....
<Channel Name="Rotating Gobo 1 change">
  <Group Byte="0">Gobo</Group>
  <Capability Min="0" Max="17" Preset="GoboMacro" Res1="Others/open.svg">No gobo</Capability>
  <Capability Min="18" Max="35" Preset="GoboMacro" Res1="ClayPaky/gobo00067.svg">Gobo 1</Capability>
  <Capability Min="36" Max="53" Preset="GoboMacro" Res1="ClayPaky/gobo00059.svg">Gobo 2</Capability>
  <Capability Min="54" Max="71" Preset="GoboMacro" Res1="ClayPaky/gobo00068.svg">Gobo 3</Capability>
  <Capability Min="72" Max="89" Preset="GoboMacro" Res1="ClayPaky/gobo00069.svg">Gobo 4</Capability>
  <Capability Min="90" Max="107" Preset="GoboMacro" Res1="ClayPaky/gobo00070.svg">Gobo 5</Capability>
  <Capability Min="108" Max="129" Preset="GoboMacro" Res1="ClayPaky/gobo00071.svg">Gobo 6</Capability>
  <Capability Min="130" Max="255">Gobo shake</Capability>
</Channel>
<Channel Name="Gobo 1 rotation">
  <Group Byte="0">Gobo</Group>
  <AffectedChannel Index="8"></AffectedChannel>
  <Capability Min="0" Max="127">Fixed position</Capability>
  <Capability Min="128" Max="190">Fast to slow rotation</Capability>
  <Capability Min="191" Max="192">Stop rotation</Capability>
  <Capability Min="193" Max="255">Slow to fast rotation</Capability>
</Channel>
<Channel Name="Gobo 1 fine" Preset="GoboWheelFine">
   <AffectedChannel Index="8"></AffectedChannel>
</Channel>
....

P.S. AffectedChannel is a rather clunky name. What about "Modifies" or "Prerequisite" or "Prereq" or perhaps you have an idea....

Posted: **Mon Jun 08, 2020 8:07 am**

Any thoughts on the proposal posted on the 1st of June?

Posted: **Fri Jun 12, 2020 10:17 am**

If there are no further comments, we will start working on implementing the changes described above.

Posted: **Mon Jun 15, 2020 8:13 am**

Again, no to indices in channels. Yes to using the ones already present in modes.
And by the way what you explained is a channel ID, not an index.
In modes, instead there are real indices and I prefer to force the creator to specify for each mode when a channel affects another channel. From mode to mode they can actually change the behaviour. (the channel they affect)
With your proposed solution you can't.

On Clay Paky Alpha Spot 575

Code: Select all

...
 <Channel Number="8">Fixed gobo change</Channel>
  <Channel Number="9">Rotating Gobo 1 change</Channel>
  <Channel Number="10" ActsOn="9">Gobo 1 rotation</Channel>
  <Channel Number="11">Rotating Gobo 2 change</Channel>
  <Channel Number="12" ActsOn="11">Gobo 2 rotation</Channel>
...

As simple as that. If a channel is removed, links are broken and removed too.
OK?

Posted: **Thu Jul 09, 2020 8:07 am**

OK. We can live with this approach.

Next Question:
In one of the pull requests we recently submitted had a small change rejected where:

Code: Select all

<Capability Min="8" Max="15" Preset="GoboMacro" Res1="">Gobo 1</Capability>

With the comment that

Using GoboMacro/GoboShakemacro without a picture is a useless information.

However, adding GoboMacro in this case is useful. Doing this makes it possible to present the user with ALL gobos on a wheel while leaving out extra functions like "stop rotation" and "wheel rotation". The user can then be sure they are selecting a gobo, even though the preview image is missing.

Looking forward to hearing your thoughts.
Ray Console Team

Posted: **Tue Jul 14, 2020 8:37 am**

Any thoughts on the comment posted on the 9th of July?

Posted: **Tue Jul 14, 2020 12:39 pm**

What I meant with my comment was: when previewing gobos (e.g. in the 3D preview), having that information or not is quite useless because in any case I won't be able to represent the real behaviour of the fixutre.

However, I understand it might be useful to distinguish betwwen a gobo and something else, as you said.
I can even modify the preview code to display a number if the gobo picture is not available. QLC+ 4 does that already.

So OK, lets do this as well. Thanks

Posted: **Wed Jul 15, 2020 9:44 am**

OK. Thanks you for agreeing. We will prepare a pull request with the agreed changes.

Posted: **Fri Jul 17, 2020 7:08 am**

mcallegari wrote: ↑Mon Jun 15, 2020 8:13 am Again, no to indices in channels. Yes to using the ones already present in modes.
And by the way what you explained is a channel ID, not an index.
In modes, instead there are real indices and I prefer to force the creator to specify for each mode when a channel affects another channel. From mode to mode they can actually change the behaviour. (the channel they affect)
With your proposed solution you can't.

On Clay Paky Alpha Spot 575
Code: Select all
...
 <Channel Number="8">Fixed gobo change</Channel>
  <Channel Number="9">Rotating Gobo 1 change</Channel>
  <Channel Number="10" ActsOn="9">Gobo 1 rotation</Channel>
  <Channel Number="11">Rotating Gobo 2 change</Channel>
  <Channel Number="12" ActsOn="11">Gobo 2 rotation</Channel>
...
As simple as that. If a channel is removed, links are broken and removed too.
OK?

I've got a question about your preferences in the application development and add new "actsOn" index in mode's channel. Now, you've got QVector <QLCChannel*> for store channels pointers in mode class. I see two solutions for connecting the channel with acts on the channel in mode:

1. Change QVector <QLCChannel*> m_channels; for QVector of structure, which contains two pointers first one for channel second one for acts on the channel.

2. Add the second list or hash in mode class for store channels and acts on channels.

Which solution do you prefer? Maybe you have another idea/solution?

Posted: **Mon Jul 20, 2020 3:51 pm**

Any thoughts on the comment posted by kluszon on the 17th of July?

Q Light Controller+

Update Fixtures with Gobo Presets

Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets

Re: Update Fixtures with Gobo Presets