RgbScript make stage colors available to scripts

[hjtappe]

Hello @mcallegari, this pull request extends the rgbScript API by the raw colors as set in the UI in addition to the step color.

Effectively, this allows synchronization of RGB script colors to stage colors, also for multicolor scripts and specifically extends the available colors from a list of predefined colors to the complete RGB space as used on stage:

• alternate.js can now make direct use of the stage colors
• ballscolors.js can now have balls which follow the stage color
• plasmacolors.js can now display plasma following the stage color

It also introduces error evaluation on the QJSEngine::call calls, so script errors would not only be while loading the scripts (::evaluate / static analysis, missing brackets etc.) but also in dynamic evaluation (::call / undefined indices etc.).

There is more potential in this approach, like adding more (up to five) colors in the UI, but I did not yet want to interfere with your UI thoughts before presenting the general concept.

Please evaluate if this could be a useful extension to QLCplus and let me know your thoughts.

[mcallegari]

Preliminary question: what do you mean by "stage colors"?

[coveralls]

coverage: 31.573% (-0.4%) from 31.983%
when pulling 4147c93 on hjtappe:rgbScript-colorArray
into 5f77fc9 on mcallegari:master.

[hjtappe]

Preliminary question: what do you mean by "stage colors"?

In stage scene productions, often two or three colors are used consistently across the stage elements at a time. Changing the color dropdowns is tedious in RGB matrix controls, so binding the startcolor and stopscolor to the colors used on stage anyway in sequences or through color control buttons would automate the consistency.

The alternative is to prepare these scripts once for every color combination that you foresee to have them quickly accessible, but that leads to an unnecessarily crowded workspace.

Please find attached an example workspace which shows the effect of stage colors changing every 7 seconds and the matrix colors following them, visible in the 2D view and the Virtual Console. It runs on compile-qt5-AppImage / qlcplus-qt5-4.12.7_GIT-20230419-db0090d.AppImage.

stageColors.qxw.zip

(it also runs on the qt5qml build, but I am still faster in building the space quickly in the old UI)

[yestalgia]

Forgive me if I'm wrong, but how is this different to using the custom controls?

[hjtappe]

Forgive me if I'm wrong, but how is this different to using the custom controls?

You mean the script properties?

The differences are:

• the properties contain only 30 colors (plus black and white) and are missing some well-used colors which cannot be set unless you create a custom version of the script. --> The direct colors can follow all colors that are used on stage and set through color controls.
• the properties cannot be synchronized to other colors on stage. Unless you have fixed scenes and duplicate the scripts instances per scene or you click multiple times to set other stage colors and choose the matching color names in the script, colors will not synchronize in time and value. --> The direct colors can be configured to automatically follow other stage light RGB channels through the VC matrix widget and will instantly take over the color selected through a scene or collection.

The latter one is a real pain to me in dynamic productions which rely on the lights to dynamically follow the stage emotions (from improvization theatre to freestyle music jam sessions). For the first one it is just inconvenient to think about a good color name - but it becomes a pain when it does not change in the rhythm of music due to the additional thoughts and clicks.

Is that what you were asking?

[hjtappe]

Hello @mcallegari,

I integrated the new marquee.js into the QLCplus workspace (there seems to be use for the feature to have the raw colors available in the scripts ;-) ), but I also found off-by-one and update errors, which I fixed along the way. Please let me know if I should create another marquee.js pull request with just these changes:

• Changing / Fading colors (color-1) were not taken over into the background
• The integer in properties "16" + "3" + 1 were interpreted as string (1631) - added parseInt a few times
• The edges of the marquee were set twice, each edge had it's own way to start over. This leads to each edge having an inconsistent marquee pattern.
• The selected marquee color is not applied but added (merged) with the background color. This significantly reduces the reachable color space for the marquee. It could be made an option, but if the user needs merged another on the marquee, he could select the marquee color right away.

The VC and 2D view now look like this:

This is the QLCplus workspace file:
stageColors.qxw.zip
created, tested and run with this build:
https://github.com/mcallegari/qlcplus/suites/12515946079/artifacts/667974953

[hjtappe]

@yestalgia, thanks for your review and nice video. As you mention, this will enable us to connect the colors used in light animations (rgbscripts) to sync, fade and follow.

I have merged master, so you will be able to give it a try after the build has finished.

Regarding the knobs, there are two reasons why I would not change them: I would not change the v4 UI concepts any more. And the users will want to set the colors with multiple knobs per color "channel" (one for each color preset they define) when they use the VC in a light-scheme kiosk terminal. In that use-case, you want to add pre-defined buttons to switch between color presets.
For the simple user - the more experienced user would actually apply a scene on a VC button...

I would be happy to see this merged into master because then I can use rgbScript animations (including "plain color") all over the place and use those to manage the show in a more consistent color style.

[mcallegari]

@hjtappe the idea is approved, no doubt about it. Thanks for this. I'm pretty sure many users will appreciate it.
However I would like to discuss with you a few decisions you took in the code.

1. considering the size of this change, why 5 colors and not an arbitrary number of them? I would change
   QColor m_rgbColors[RGBAlgorithmRawColorCount];
   to
   QVector<QColor> m_rgbColors;
   Then when loading the script for the first time, the C++ code will resize the array to the size defined with algo.acceptColors. If version < 3 or no variable is defined, the array should be resized to 2 to handle start/end.
2. I don't quite like the idea of passing the colors array at each rgbMap call. This affects performances (even if slightly...but still) and most likely colors won't change that much in time. Instead, I would add a method to v3 scripts to set colors by index, as you did in the C++ code.

I have mainly these 2 concerns for now. What do you think?

[hjtappe]

Hello @mcallegari, thanks for your positive inputs on this.

Yes, the number of 5 is arbitrary - but seems like a good statistical assumption these days:

• I believe the number will not increase significantly because managing much more colors will become increasingly complex to manage for the operator and will create a confusing stage I believe.
• One operational mode could be using a rainbow script to drive the "virtual" (loopback) colors and attach other scripts colors on the second logical level to the slots in the rainbow colors. In that case of color change automation, the number is running higher.
• Much larger numbers will clutter the current color picker layout in the UI, so I would please need assistance to define and implement e.g. a new popup screen or a dynamic table and I wonder if we would do that step once v4 is no longer maintained.

1. QVector: I can certainly rework the code, load and store and probably the script interface the to handle and work with a QVector. Unfortunately, I have no idea how the dynamic table in the UI and QML and Webaccess code would be implemented. If you have examples in the code, I can try to learn how to apply the implementation pattern to these colors.
2. Script method to set colors by index: I can extend the v3 script API to initialize and handle color changes through a method. Instead of calling that function for each color (especially when not limiting the color count), I would implement one function to update the colors as an array. For some scripts, it might even be interesting to hand over the steps-timing to scale pattern movements to align smoothness of patterns with speed of movements. Thinking about performances, when putting that into each call, doesn't it mainly increase the memory footprint of that function? I fear that another method being called might have a much higher performance overhead due to the Layers of API between C++ and JS being involved.

So let me do the next moves:

1. Look into how to modify the v3 script JS API with the additional method.
2. Start implementing the dynamic QVector in the C++ code as well as load and store, so we are future-proof and unlimited on the data and business logic side.
3. Leave the UI, QML and Webaccess limited to 5 for the moment, so we can take a look into how and when this can be extended for an unlimited range within an acceptable user experience.

One capacity note: I am quite busy throughout the summer, so it could take a while to the next commit, but I am happy for the guidance you provided for the next steps.

[yestalgia]

Hello gentlemen,

Just wanted to check in on this guy. @hjtappe are there any additional tests you want me to do on Windows?

I'm getting a lot of interest from the Resolume community here in Melbourne about the smooth colour transitions possible with this.

Thanks again

[hjtappe]

@yestalgia , thanks for your offering. I have been using the Github builds to check the functionality, so feel free to run it to check it from other perspectives if anything might break that I might have overlooked. But I have no Windows specific areas of test in my mind (might be a bind spot).

The current status is: the Qvector change is implemented. The API change is pending a measurement test which approach really saves compute time as well as my current lack of capacity during summer. The dynamic number of dials integration into the UI topic is still open and probably will remain limited until we have an idea on how it should look like.

[hjtappe]

On a side note, I have been peeking into the idea of screengrabbing to foster a TV backlight effect on large conference screen at https://github.com/hjtappe/qlcplus/tree/rgbMatrix-screenGrabber

Grabbing colors from a screen on the same desktop already works, but I failed so far on grabbing from an HDMI grabber or Camera device through the QMultimedia framework due to the asynchronous behavior.

That might be of interest for the community as well, @yestalgia
That's why is is not yet pushed as a draft pull request. But if there would be anyone to help taming the QT framework... 😀

[yestalgia]

On a side note, I have been peeking into the idea of screengrabbing to foster a TV backlight effect on large conference screen at https://github.com/hjtappe/qlcplus/tree/rgbMatrix-screenGrabber

[Off-topic] Dude absolutely! NDI is also something I'm looking at.

Happy to sponsor this feature if you'd be willing to accept a donation. Send me a DM on Instagram or the forums. Here is a link to current discussion:

https://www.qlcplus.org/forum/viewtopic.php?p=74017

[yestalgia]

Let me know when you want some UAT done. I'm still very excited about this revamp.

[hjtappe]

I think I have now finished implementing the changes, except for the UI, which is still statically limited to 5 entries at most. I will need some support to modify the UI code (which I have zero experience with) to dynamically respond to more colors. Due to the bitmaps used in the code, I think, there is still a limit of 32 or 64 colors at most and we may need to ensure that in order to prevent wild ideas which lead to buffer overflows.

[mcallegari]

I think I have now finished implementing the changes, except for the UI, which is still statically limited to 5 entries at most. I will need some support to modify the UI code (which I have zero experience with) to dynamically respond to more colors. Due to the bitmaps used in the code, I think, there is still a limit of 32 or 64 colors at most and we may need to ensure that in order to prevent wild ideas which lead to buffer overflows.

Hey @hjtappe thanks for this!
Which UI are you referring to? v4 or v5?
I would also improve the preset creation to support any number of colors. Please leave it to me. Just point me to where you need help. Thanks

[hjtappe]

Both UIs are currently restricted to 5 colors so far. It would be great if you could help with that. I would otherwise need to spend some time with one of the coding AIs to help me out finding the path (and maybe tools to use for the UI work). ;-)
Do I need to set the PR from draft to "ready for review" to unblock it?

[mcallegari]

Do I need to set the PR from draft to "ready for review" to unblock it?

I have done it.
To allow me to work more easily, can you please move this PR to the branch I've just created named "stagecolors"?
I think it can be done via GH web UI

[EDIT] I've been able to do it myself. Gonna merge this there then

[mcallegari]

I'm confused.

Why do we need alternatecolorsdirect.js? alternatecolors.js already had 2 steps (fixed in the JS code) so the two colors are already handled by the QLC+ engine. [EDIT] my bad. Wasn't remembering this one correctly. In any case it would be good to have a single script (see below)

Also, is ballscolordirect a replacement for ballscolor?
Same for plasmacolorsdirect.
In general, can we just set some default colors in the JS script and keep one single script that produces multiple variants?
E.g. Plasma Preset property: User defined (5 colors available), Rainbow, Fire, etc.

Therefore, I think a "rgbMapGetColors" is needed as well so the UI can get default colors from a script.

If there's cleanup you intended to do, please let me know.
QLC+ users are already confused by the (too) many options. Let's not add complexity to this rather simple functionality.

[hjtappe]

Hello @mcallegari

Why do we need alternatecolorsdirect.js? alternatecolors.js already had 2 steps (fixed in the JS code) so the two colors are already handled by the QLC+ engine. [EDIT] my bad. Wasn't remembering this one correctly. In any case it would be good to have a single script (see below)
Also, is ballscolordirect a replacement for ballscolor?

You may decide to overwrite the original scripts. Reason is the consideration of a compatibility issue with existing show files.
If we would merge them, we would need to keep the color dropdowns (to be read from the show files) and pick them up as the start color.

Thank you for working so quickly on the merge!

[mcallegari]

foreach (QColor col, mtx->getColors())
    m_rgbColors.append(col);

But it won't apply the colors to the algorithm.
Why isn't there a m_algorithm->setColors(m_rgbColors) in the setAlgorithm method?

[hjtappe]

In line 304, setStartColor() is replaced by a generic setColor(), which here is called a few lines later after your commented line (line 181) while iterating through the colors. That then sets the colors to m_algorithm->setColors in line 313.

[mcallegari]

Hey @hjtappe just making sure you received a notification for my comment on this commit
6cd67bd

Can you please help to review?
Let's finalize the work on that branch and merge it to master! Thanks

[hjtappe]

Hey @hjtappe just making sure you received a notification for my comment on this commit

Yes, I try to fit that into this weekend.