RgbScript make stage colors available to scripts

[hjtappe]

trafficstars

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.62% (-0.4%) from 32.027% when pulling 05fd4b369ac0babce7c7e60f9cfefb275404a9cf on hjtappe:rgbScript-colorArray into aeab64e8b82729bfdcfed11fd843e53723e23782 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]

I separated side aspects of this work into pull requests #1423 and #1424 and will merge master back here once the other pull requests are discussed and merged into master.

[hjtappe]

The color dropdowns in some API v2 scripts provide a limited functionality regarding color setting as the original scripts API only copes with one color at a time, alternating or fading from one color to the other.

With this this, updated API v3 concept , the scripts can:

• be set to arbitrary color values, matching the colors used on stage and are no more restricted to the colors in the list
• use both colors in one matrix, not just one
• fade the colors in sync with the stage colors rather than jumping between color values from the dropdown
• change the colors synchronously to an external input, not just sequentially as the dropdowns are changed

This is how the attached workspace makes use of it:

[mcallegari]

@hjtappe here I am, sorry for the delay

To be honest I still don't understand the need of this quite big change. It is already possible to

• set a color via Scene/Click And Go
• output to loopback
• input on VC Animation widget start/end colors
• therefore change a matrix while running (programmatically)

This is basically the diagram you posted above (thanks for that!) So can you please explain (perhaps again) what is this PR adding to the mentioned data flow?

Thank you

[hjtappe]

Hello @mcallegari,

As you say, the basic scheme is already implemented. But it works only for those scripts which apply only one color per step, i.e. they use the calculated stepColor "rgb" (as in evenOdd etc.).

Scripts which apply more than one color per step (plasmaColors, ballsColors, alternate, etc.) could not be set through the Click&Go colors and had been programmed to acceptColors=0 and a limited set of dropdown color names. Those are the scripts which had been modified in this patch.

This patch makes not only the single calculated stepColor "rgb" available to the scripts, but the array of colors that has been set:

• The variables startColor and stopColor are moved into an array of fixed RGBAlgorithmRawColorCount size
• This array if pushed into the new script API apiVersion 3 as rawColors
• UI and qmlUI have been modified to access the array instead of the startColor and stopColor
• The affected scripts have been modified to the new API version 3, acceptColors=2 and the first two color dropdowns have been removed

What can still be decided:

• Forward an array of only two colors through this API or an array of up to 5 colors? This would remove the remaining 3 (of currently 5) color dropdowns in the more complex scripts, but it would have impavt on the UI as well.
• Modify the scripts as a more or less breaking change with the introduction of v5 or leave the old scripts as a legacy (they still work, but lack the color synchronization)
• Provide possibly even more information to the script through the apiVersion 3, such as timing information

[mcallegari]

OK, the "forward any number of colors to scripts" is clear to me. What I don't get is how you control all those colors from the virtual console. Animation widget is clearly limited to 2 (start / end) In this case the "Attributes" introduced in v5 could help, but first I would like to fully understand your proposal.

[hjtappe]

This patch only controls the existing first two colors, but is prepared to extend it to (e.g. 5) colors (maximum currently used in the scripts). This means, the widgets are not updated to be extended, but use the available two color selections so far. Thus no change yet at that area and the colors 3-5 are still a dropdown in the scripts so far.

If you would like the extension to 5 colors to be done, I would update the affected widgets as well. I have not done that yet because that seems to be are rare case (I suspect 2-3 colors on stage as a manageable maximum), but I understand that this would make it more complete. Nevertheless, the upper limit of possible colors would always need to be limited (by RGBAlgorithmRawColorCount, specifying the size of the digested array).

[hjtappe]

Setting this to draft while working on UI support for the multiple colors and merging the new qmlui matrix widget updates from master.

[hjtappe]

The v4 ui code, the v5 QML ui code and the webaccess code have now been updated to support scripts to use up to five colors. I might still need to cover the one or the other place in testing.

As an example, ballscolors.js now can follow the colors set in up to five fixtures in the full RGB color space and the user does not necessarily need to switch in the limited script control parameters to select from the list of pre-defined colors.

Thus, the colors in the Matrix instantly follow the fixture settings and the user does not necessarily need to store scenes for every foreseeable color scheme on stage to synchronize color change.

[hjtappe]

I have now created copies of the matrix scripts which were in need for the direct color access and merged the master back into this branch.

So with this, the QLC+ users will be able to synchronize the plasma and alternate, marquee, balls etc. colors on two panels on the same stage with changing only one set of leading color channel which the matrix can sync it's colors on.

So while it was previously possible to create matrix effects

• for single color patterns
• for mask patterns
• for color patterns fading between two colors
• for multi-color patterns which needed a dropdown to select the color this patch will add the possibility to create matrix effects
• for multi-color matrices with direct access to color scene changes
• for multi-color matrices with synchronized color selections without the need to duplicate the matrices and all its setting to integrate them into collections for each color scheme.

[yestalgia]

Being able to fade colours of the rgbmatrix would be a super interesting way to perform live. I'm keeping a close eye on this.

Appreciate the effort @hjtappe

[hjtappe]

The file matching the renamed algorithms got lost in upload (probably rejected), so here it is: stageColors-5.qxw.zip

About 90% of the shows I volunteer for are freestyle where I react on what I hear. Only 10% is somehow predictable or theater style. So having direct access (e.g. in alternate.js) to the colors will help me putting colors and patterns on stage consistently and instantly. :-)

[yestalgia]

@hjtappe I'm doing some tests on my windows machine based on the last build.

Can you please merge master into this branch so I can check it with the latest changes?

[yestalgia]

I've done some testing on Windows and there are things I LOVE about this. Also some things which I think could be improved.

The good:

As a heavy user of the Animation widget, I've always wanted to be able to send input to change the colour of the start and end colours. But this is even better! We can now control up to 5 colors within the matrix which is ace. This is really forward-thinking stuff which will allow many possibilities for those developing RGB matrix scripts.

Suggestion:

This said, I don't see a reason to have both "Add Color 1" and "Add Color 1 Knobs" cluttering up the animation widget properties dialogue. If controlling the colour of the matrix should be done externally through RGB values sent via loopback, then I think we should commit to it.

For this reason, I believe we should make the Knobs controllable via loopback and remove the preset colors (as in "Add Color 1")

However I'm open to discussion on this. One way I think you could still have presets (and not break anyone's showfile) is an "Add Color" button. Then you could select which color this applies to (1,2,3,4,)

Excellent work.

Tested using Windows 11

[yestalgia]

Hey guys,

Here's a video showing my testing: https://youtu.be/VChztAg9Xxc

This is SERIOUSLY cool.

[yestalgia]

@hjtappe I did some further testing. Just an aesthetic point:

Can you please make sure there is a nice grid of buttons for the colour selection? This can be done by adding whitespace or a disabled X button instead of the first colour being larger.

[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<QColor>: 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<QColor> 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