Q Light Controller+

Hey Massimo,

I'm seeing you're very busy implementing stuff for QLC+ 5 and I highly appreciate it! Since I'll have some spare time this summer I wanted to offer help. This may include implementing things in QLC+ 4/5 or maintenance stuff so you can spend more time on the things that are really important at the moment.
So I thought it would be great to have a thread somewhere with tasks that need to be done and someone might pick up if there is time.
In addition to that, guys who have free time can give an overview of their experiences and maybe there is something you can assign to them.

As for the help I can offer: You know I have some experience in programming and already made some pull requests (some better, some worse I know). In addition to that I'm familiar with basic web-related stuff (PHP, css, databases and so on), Linux, Raspberry Pi and a little bit low-level programming.

Regards and keep up the good work,
Lukas

Hi Lukas, first of all, thanks for offering.
There would be numerous activities in the TODO list, but most of them require my supervision (and you know how picky I am for code contributions... )
Also, it is longer to explain in text than looking at the code together in person. Since we can't do the latter, I need to think what can be explained easily in a way that we both won't waste our time.

One above all, I will need a lot of manpower for a big rework I intend to do on fixture definitions. Again, I need to write down the enums to start with. I'll create a new branch in the next weeks.

Maybe you can start with this: viewtopic.php?f=33&t=11658#p50079 since you're the one who contributed the feature in the first place.
I haven't had time yet to check the code, but I think input profiles could start getting too crowdy if we don't find a flexible solution future-ready.
I am referring to m_midiSendNoteOff for example. Right now there's only one "global" flag but they can increase over time.
So I propose to make it a generic quint32 m_flags and SendMidiNote would become a bit like (1 << 0)
Then HasMotorizedFaders would be (1 << 1) and so on. So we create the space for 32 boolean flags that can be masked together.

Don't know if you got what I mean. In case let's continue this via email or GitHub.

Cheers

P.S. Have you seen my latest blog post ? I thought about you when I implemented multiple fixture items dragging

mcallegari wrote: ↑Sun Feb 04, 2018 6:16 pm Maybe you can start with this: viewtopic.php?f=33&t=11658#p50079 since you're the one who contributed the feature in the first place.
I haven't had time yet to check the code, but I think input profiles could start getting too crowdy if we don't find a flexible solution future-ready.
I am referring to m_midiSendNoteOff for example. Right now there's only one "global" flag but they can increase over time.
So I propose to make it a generic quint32 m_flags and SendMidiNote would become a bit like (1 << 0)
Then HasMotorizedFaders would be (1 << 1) and so on. So we create the space for 32 boolean flags that can be masked together.

Don't know if you got what I mean. In case let's continue this via email or GitHub.

I didn't have a look at this part of the code yet but I guess I know what you mean. I'll have a look into this and give you updates in the next few weeks/months.

mcallegari wrote: ↑Sun Feb 04, 2018 6:16 pm P.S. Have you seen my latest blog post ? I thought about you when I implemented multiple fixture items dragging

Yes I have, this is pretty amazing! Great you remembered and considered this - would also be nice to have in the vc. But especially the distance tool is already more than I ever imagined (:

Hi Massimo,

we thought about adding more information to capabilities in our JSON fixture format in the Open Fixture Library some time ago (see the issue on GitHub). Your latest QLC+ 5 preview post which suggested that you are working on a new fixture format reminded me of that issue again and I structured my ideas a bit more there and added a note about the pan / tilt direction (clockwise / counterclockwise).

Maybe you want to have a look there to see what we thought of yet. It would be nice if we could develop new ideas about QLC+'s new fixture format together, so that we can both cover as many use cases as possible

I'm really looking forward to seeing the 3D view in action! If a new fixture format is the sacrifice needed for this awesome feature, I think it's worth it

Regards
Flo

floEdelmann wrote: ↑Mon Feb 05, 2018 9:35 pm Maybe you want to have a look there to see what we thought of yet. It would be nice if we could develop new ideas about QLC+'s new fixture format together, so that we can both cover as many use cases as possible

Hi Flo, indeed I considered the ideas you guys implemented in OFL and I actually wanted to send you an email.
I was only waiting to publish those 2 videos which took me a lot of time cause of many last minute issues to fix.
In the next days/weeks I will open a new branch and prepare the ground for the fixture definition rework. I will also try to come up with a brief document explaining what I have in mind.

Then I'll send you the email

I/we will probably need to write some scripts to convert the existing fixtures to the new syntax. There will be numerous advantages but it will be a lot of work.

Massimo, it may be useful to keep the new fixtures discussion here in the open instead of emails, so more people may chime in.

Here are few fixture ideas:

- explicit shutter values so no guessing needed
- more precise light source description (RGB/RGBW/... LED, White LED, halogen,... even maybe distinguish between X-in-1 and separate R/G/B leds)
- separate category for primary color channels (R/G/B/C/M/Y/A/W/...) so they don't get confused with color wheels/macros ("primary colors" is not
a good name, I haven't come up with a better one)
- separate category for dimmer channels so they don't get confused with primary colors
- distinguish between color wheels (subtractive) and color macros (for LED engines) that override the color
- proper 16-bit description (explicitly mark LSB and MSB channels that belong together)
- add comment field (for e.g. fixture definition author's comments about the definition)
- add alias field (when the same definition applies to more fixtures)
- add fixture URI (to manufacturer page)
- add manual URI (to fixture manual/pdf)

These are easily implementable without big changes to engine.

Few more that would require big engine changes:
- drop the "raw" DMX approach, extract fixture "attributes" like color, beam, position etc. and work with that. Instead of working with Pan Coarse and
Pan Fine work with one 16bit channel Pan, and split it to individual bytes at the very last stage. For simplicity/performance sake, it might even make
sense to work with 32bit channels. On the other end of spectrum, one attribute may cover only part of a DMX channel (when one DMX channel contains
several attributes like 0-127 dimmer, 128-255 strobe). In similar case the attributes would be exclusive to each other. In this manner also dependent
channels might be solved...
In color case, this means that QLC+ would internally work with whatever makes sense (like RGB model) and it will be rendered/converted to whatever
color model the fixture uses. This would solve HSV/HSI/CMY fixtures. This is how big guys (avolites, hog) work. You don't select individual RGB values,
you select the color (in a color model convenient to the operator).


Lukas, one of easier tasks might be to implement multiple output patching for QLC+4 (one universe to multiple outputs). The engine part is almost
there (for QLC+5), what needs to be added is the GUI part.

Jano

Jano, I don't know why you often disapprove my posts in this forum, but I'm more interested in people that actually do things rather than people who throw a lot of theory and then don't implement it. It's always easier to tell others what to do instead of doing it.
Will you be the one supporting Lukas in the multiple output implementation ? Will you be the one fixing the code if users will find bugs on it ?
I think the answer is no. It's always me, because I take the responsibility for what I (and others, including you) do on the code. Would you be willing to do the same ?

This https://github.com/mcallegari/qlcplus/issues/696 is there "in the open" since Nov 2015, and it doesn't seem to me "more people chimed in".

I've started the rework on a branch named "newdef".
Here's a document I just wrote, describing my intentions:
https://docs.google.com/document/d/1cnH ... sp=sharing

Channel presets is already in place, including in the definition editor.

@Flo: this will change fixture definitions a lot, and will break the OFL QLC+ parser.

This looks good to me.
Please don't mind me adding some extra "wishes" since I actually consider some of Jano's ideas pretty helpful. These include:

janosvitok wrote: ↑Tue Feb 06, 2018 9:26 am - separate category for dimmer channels so they don't get confused with primary colors
- distinguish between color wheels (subtractive) and color macros (for LED engines) that override the color
- add comment field (for e.g. fixture definition author's comments about the definition)
- add alias field (when the same definition applies to more fixtures)
- add manual URI (to fixture manual/pdf)

The alias field could serve as identifier for all the Chinese fixture clones some of the members are so goopy about. Having the manual as a link at hand will be very helpful (although I know these will get corrupted pretty soon).
I think we should think the whole rework over very well to make the fixture definitions as future proof as possible.

Here's my comments item by item

- 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

- distinguish between color wheels (subtractive) and color macros (for LED engines) that override the color

This can be easily done by marking a capability with a preset. Might be "ColorWheel" and "ColorMacro"

- 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.

- 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.

- add manual URI (to fixture manual/pdf)

This is a bad idea in general. If you ever visited StackOverflow you might have noticed that most of the times external links are broken.
Also, see above. "Free fields" will be abused.

I think we should think the whole rework over very well to make the fixture definitions as future proof as possible.

I agree.

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.

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: 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: 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?

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.

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.

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.

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+.

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