How to help?

Post Reply
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

mcallegari wrote: Sat Feb 10, 2018 12:14 pm - separate category for dimmer channels so they don't get confused with primary colors

This is an implementation nightmare. Adding/removing a channel type involves god knows how much effort all over the code
I didn't mean to do this all over the program, because I think this is already clearly separated in simple desk and function manager. But it can easily get mixed up while making new fixture definitions since all the channels involving dimmer or color have the "intensity" type. So I would propose to change this to a more clear separation, ie introducing a new channel type "dimmer" for example. Internally we can still handle it as an intensity channel but it will be more clear to the user.
mcallegari wrote: Sat Feb 10, 2018 12:14 pm - add comment field (for e.g. fixture definition author's comments about the definition)

I disagree. I already received fixtures where smartass people try to advertise their website by adding a URL to the author field.
The more freedom they have, the more they will abuse of it. We must start from the fact that QLC+ users are not disciplined and don't follow the common sense rules.
I see your point. The question is how to balance the disadvantage of maybe having a little more work on reviewing fixtures against the advantage of having some additional information about the fixture available (maybe a behavior QLC+ can't handle or even information about setting the correct mode on the fixture). Since you are the one reviewing the fixture definitions as last instance I don't have the right to do this weighing but I encourage you to at least consider it.
mcallegari wrote: Sat Feb 10, 2018 12:14 pm - add alias field (when the same definition applies to more fixtures)

I have no strong opinion about this, but the definition map works by manufacturer/model. I see it difficult to expose a definition for multiple instances of them.
The aliases could simply be added to the searched tags in the adding fixtures dialog so it would be displayed under the normal (first) manufacturer with a hint.

In general, I like the idea of teaming up with OFL since they make some good points (especially in the mentioned issue report) and it would be a waste of time if both of the projects think about a rework and necessary capabilities simultaneously.
User avatar
Fxedel
Posts: 25
Joined: Fri Nov 17, 2017 6:42 pm
Location: Munich, Germany
Real Name: Felix Edelmann
Contact:

In OFL, we optionally store manual URLs. Detecting broken links is done with a test script that runs with Travis and posts a GitHub comment if a manual url is broken - if it remains broken for a few days, we search for an alternative, and if we can't find an alternative, we'll remove the url sometime. Having a reference to the manufacturer's instructions about a fixture is pretty useful. For example, when we extend our format to be more exact / specific, we can quickly find the manual and examine the exact information. And as an end user, it's useful to know where to quickly look up if there's something unclear when (physically) installing a fixture (however, this might be an OFL-specific point). In my opinion, the only disadvantage against an optional manual url are spammers / advertisers, which seems to be a big problem with QLC+'s fixture proposals.

In general, unit tests for fixtures (that run with Travis and are required to pass) are a valuable component. It helps you detect broken fixture definitions: Right after creation, but also over time when new features are added and/or fixture requirements/regulations have been changed. Think about the dependent channels: They might make fixtures a bit more complicated and decrease the chance to spot errors by hand. Maybe it's also possible to warn about possible optimizations (like replacing a channel with a preset).
The xml schema plays an important role here as it declaratively describes how a fixture should look like. It therefore catches many possible errors using an easy-to-read format. Some requirements (like correct usage of channel names) have to be checked with an extra script. I know there's already a script that checks all fixtures against the schema, but as far as I know, it's not a required Travis test and the console output wasn't very readable to me. Anyway, that could be a good starting point! I can help implementing this point, if wished, as it doesn't require much background knowledge about how the QLC+ engine and UI work (or does it?)

The capability presets and the new possibility to define a "value range" that describes a physical entity is quite interesting. You know that we're also thinking on this topic, but haven't found a solution yet. We'll keep you informed on what happens with this topic on our side.

As of dependent channels: I'm really looking forward to seeing this feature in QLC+ fixture definitions! Just a small note:

Code: Select all

<Alias name=”Sound sensitivity” number=”7” />
would set the mode's 7th channel to "Sound sentivity", right? So we'd declare something mode-specific in a mode-unspecific scope, or in other words, the channel only works in some modes, and has to be duplicated to work in other modes in which "Sound senstivity" would be the 9th channel, for example. See cameo Hydrabeam 300 as an example that uses a switching (dependent) channel at different mode positions. I'd suggest introducing a placeholder channel (that may resolve to a default channel) and can be overridden by aliases, like so:

Code: Select all

 <Channel Name="Program Speed / Sound Sensitivity">
  <Group Byte="0">Placeholder</Group>
  <Default>Program Speed</Default>
 </Channel>
 <!-- ... -->
 <Channel Name="Auto Programs">
  <Group Byte="0">Effect</Group>
  <Capability Min="0" Max="10">No function</Capability>
  <Capability Min="11" Max="50">Program 1</Capability>
  <Capability Min="51" Max="100">Program 2</Capability>
  <Capability Min="101" Max="255" Preset=”Alias”>Sound active
   <Alias set="Program Speed / Sound Sensitivity" to=”Sound sensitivity” />
  </Capability>
 </Channel>
 <!-- ... -->
 <Mode Name="8bit">
  <Physical><!-- ... --></Physical>
  <Channel Number="0">Pan</Channel>
  <Channel Number="1">Tilt</Channel>
  <Channel Number="2">Auto Programs</Channel>
  <Channel Number="3">Program Speed / Sound Sensitivity</Channel>
 </Mode>
 <Mode Name="16bit">
  <Physical><!-- ... --></Physical>
  <Channel Number="0">Pan</Channel>
  <Channel Number="1">Pan fine</Channel>
  <Channel Number="2">Tilt</Channel>
  <Channel Number="3">Tilt fine</Channel>
  <Channel Number="4">Auto Programs</Channel>
  <Channel Number="5">Program Speed / Sound Sensitivity</Channel>
 </Mode>
Is the preset Alias really needed then? The existence of the Alias tag(s) already declares that this capability changes the dependent channel. A unit test should ensure that a placeholder channel is only affected by a single other channel (only "Auto Programs" changes the behavior of "Program Speed / Sound Sensitivity"). Maybe add a information in the placeholder channel about the "trigger channel" (= Auto Programs), or move the placeholder channel declaration into the channel tag, as they are strongly connected to each other?
Have a look at the Open Fixture Library! It's a project to collect fixture definitions in a unified format and make them downloadable for different lighting programs, including QLC+.
User avatar
mcallegari
Posts: 4464
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Code: Select all

<Alias name=”Sound sensitivity” number=”7” />
would set the mode's 7th channel to "Sound sentivity", right?
Nope, the other way around. Will set "Sound sensitivity" to channel 7 of the current mode.
Where "Sound sensitivity" doesn't initially belong to the mode, but is present in the global channels pool.
janosvitok
Posts: 1266
Joined: Mon Apr 13, 2015 7:05 am
Location: Bratislava, Slovakia
Real Name: Jano Svitok
Contact:

mcallegari wrote: Sat Feb 10, 2018 12:14 pm
- add alias field (when the same definition applies to more fixtures)
I have no strong opinion about this, but the definition map works by manufacturer/model. I see it difficult to expose a definition for multiple instances of them.
Implementation idea is that aliases are collected in FixtureMap.xml as well, and GUI has checkbox to show them or not.
Similar thing could be implemented for Input profiles, since many of the DMX controllers are just clones of the same thing.
janosvitok
Posts: 1266
Joined: Mon Apr 13, 2015 7:05 am
Location: Bratislava, Slovakia
Real Name: Jano Svitok
Contact:

Fxedel wrote: Mon Feb 12, 2018 3:29 pm In OFL, we optionally store manual URLs. Detecting broken links is done with a test script that runs with Travis and posts a GitHub comment if a manual url is broken - if it remains broken for a few days, we search for an alternative, and if we can't find an alternative, we'll remove the url sometime. Having a reference to the manufacturer's instructions about a fixture is pretty useful. For example, when we extend our format to be more exact / specific, we can quickly find the manual and examine the exact information.
This is the main motivation behind my proposal.
User avatar
Fxedel
Posts: 25
Joined: Fri Nov 17, 2017 6:42 pm
Location: Munich, Germany
Real Name: Felix Edelmann
Contact:

Something that hasn't been mentioned here are matrices, like 5x5 pixel heads or 1x12 pixel bars.

In QLC+, it's possible to group specific channels into heads, and the 2d monitor properly displays them as different light sources.

However, there are some difficulties to manage:
  • The position of the individual pixels is unclear. The heads must be sorted by XY axes (like reading a book, so head A that follows head B in the head list is either right of or below B), but this behavior isn't documentated. Furthermore, the pixel ratio is guessed from the dimensions' width/height ratio – if the fixture is quite wide and not very tall, it probably is a bar and the pixels are arranged in a single 1x9 row; if width and height equal, it must be a square 3x3 pixel head. Unfortunately, this guessing often fails, resulting in (wrong) 2-row bars. A simple width/height parameter in the Head editor would solve this, or, even cleaner, if heads would be saved as a list of lists (rows) of pixels.
  • Some fixtures have modes that allow controlment of not a single pixel, but a group of pixels. For example, a pixel bar of 12 LEDs could have the following modes with different grades of pixel controlment:
    • Master (1 RGB mixing for all 12 pixels)
    • Halves (1 RGB mixing for pixels 1-6, 1 RGB mixing for pixels 7-12)
    • Thirds (1 RGB mixing for pixels 1-4, 1 for 5-8, 1 for 9-12)
    • Individual (1 RGB mixing per pixel, 12 mixings in total)
    • Even/Odd (1 RGB mixing for pixels 1,3,5,7,9,11, 1 RGB mixing for pixels 2,4,6,8,10,12)
    There's a problem with the visualization of these pixel groups, especially with the Even/Odd mode: With the QLC+ fixture editor, it's only possible to create two different heads which results in two light beams in the monitor – although there are actually 12 different light beams. Instead of ABABABABABAB you get AB, which is somehow misleading.
    I discovered that this can be fixed by reusing the same head (by manually editing the XML, the fixture editor prohibits this). Defining 12 heads 123/456/123/456/123/456/123/456/123/456/123/456 produces 12 different light beams in the monitor, and setting channel 1 to 255 makes every odd pixel show up red.
  • Some fixtures have a not-rectangle matrix, like a Plus (+) or a circle. The easiest way to represent them is by leaving some pixels of a rectangle matrix out. Currently, empty Head tags result in pixels that are constantly white – I'd suggest completely hiding them in the monitor.
EDIT: At OFL, we use template channels to repeat similar channels; i.e. in a 6x6 matrix, we define one channel "Red $pixelKey" that later generates 36 channels "Red 1", "Red "2, ..., "Red 36". Parsing this syntax was quite complicated, and I don't know if this addition makes sense for QLC+.
Have a look at the Open Fixture Library! It's a project to collect fixture definitions in a unified format and make them downloadable for different lighting programs, including QLC+.
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

Hey Felix,

I don't have much experience working with RGB matrices but your thoughts make sense to me so far.
While reading your post another issue came to my mind. It is related to a fixture I'm about to work with. Its fixture definition is already included in QLC+. If you have a look at the DMX chart, you can see that the first channel somehow behaves as a mode select. The special thing about that is, that the number of heads of the fixture depends on that first channel, too (3 if channel 1 is between 1-15 or 1 otherwise).
So I suggest to allow the number of heads being dependent on a specific channel, too. I guess this will be hard to specify and it would be great, if someone could share fixtures exposing the same problem so we can be sure this is not only a special case.

Lukas
Post Reply