Q Light Controller+

So as I write more of these .. and support some of the people on this board; I've started to realize that some more interesting scripts could be written with some extended features:

• an array passed TO the scripts of the FixtureGroup that identified which positions actually had heads in the group. For instance the marquee.js I just wrote could work on a FixtureGroup that was designed with a circle of lights vs just knowing the height x width and computing the outer edge. I can also see where this could be useful for other rgbscripts so the bounds could be more in-line with the actual design of the group.
• A 'cacheable' flag (default: false) for rgbscripts that have a fixed set of steps and consistent output; if there was a caching layer that could be flagged to QLC, that ingested an output matrix at each step; so that the scripts only run on the first creation; and assuming no changes except 'step', QLC could just pull from cache. Would encourage people to actually use the 'step' variable passed to the scripts vs making them run more 'free'.
• an

  Code: Select all

  algo.documentation = "https://github.com/mcallegari/qlcplus/docs/rgbscript_name.md" 

  as an option so we can document the scripts right with the code base.

I think these could be useful additions that could be fairly easily backported into existing scripts.

sandinak wrote: ↑Wed Mar 15, 2023 1:09 am [*] an array passed TO the scripts of the FixtureGroup that identified which positions actually had heads in the group. For instance the marquee.js I just wrote could work on a FixtureGroup that was designed with a circle of lights vs just knowing the height x width and computing the outer edge.

Can you please elaborate on this example? Perhaps with a diagram?

The cacheable flag might be helpful for my shows. Especially for dimmer/amber/shutter modes. Could it cache multiple colours? I use an RGB matrix on "Plain Colour" with multiple colours defined as custom controls within an animation widget. The performance is pretty good but switching colours can take some time even on good hardware.

+1 for markdown documentation on these scripts.

Great post thanks for sharing.

Thanks for the response .. been thinking about it since i read it Conveniently one of our users provided a great example! Passed Array Details
So what we'd want to give scripts is the ability to identify the existence of a fixture at a position; and perhaps some level of capability? I think to start a matrix of booleans matching width and height could work, or if we wanted to allow more functionality perhaps a matrix of "Color Masks" that could be XOR'd with the derived color at that position.
Cacheable Details
So Reading the API docs, with v2 the scripts need to handle (re)initialization and identification of Change; however if a function isn't being called because we're trying to use cache data.. we're in a chicken/egg issue with the script identifying that change and letting QLC know to flush cache. So assuming QLC can manage cache here's one approach:

• QLC generates a matrix format that defines what heads are available
• on the rgbStepCount function
  • we pass Width, Height and input matrix so that the script can determine the steps required to satisfy the visual ( really if we pass just the matrix, the script can certainly determine the size on it's own; but if known perhaps saves cycles )
  • for V>=2 this JS should check state of algo.properties for change and force initialization if it changes
  • if we re-initialize for any reason we set flushCache to True.
  • we return now 2 values, the first being the step count and the second being flushCache
• on the rgbMap function
  • we add passing the matrix so the script can correctly (re)initialize if it changes
  • when we return we add a 'cacheable' flag to notify QLC that the data can be reused
• once all the data is computed and we have cachable data for each step, rgbMap will no longer be called
• if at any point QLC receives the "flush" from rgbStepCount it will invalidate the entire cache and (re)start calling rgbMap

I did some testing putting the cache in the javascript, but couldn't really tell for speed. I am in the process of writing some tools to help us work on testing speed/timing of large arrays for ArtNet that I think will help with this effort; Moar coming.

That's a handsome looking example. lol

The cache flushing would make the program a bit lighter to operate with a large number of pixels, no?

Yea .. the hope is that by not having to run the JS engine to do the full compute of a 'step' we can recover that compute time. I am also looking at FastLED libs and using some of their work to add more fun features in RGB Engines .. so more light weight we can make the processing better I'd think.

I’m in. I am available to do any sort of testing as this is developed. I can send any logs.