sdkGetEvtArrayColor

[sm_jamieson]

The SDK incudes sdkGetEvtArrayColor() and sdkSetEvtArrayColor(), which return TColorUsine, so they support arrays of colors. I wish to use this in a module to provide colors for midi channels 1 to 16. Instead of 16 color parameters, it would be useful to have a single array of 16 colors.
But are there any modules or a color picker that outputs a color array in order to use such a parameter ?
Simon.

[sm_jamieson]

Well color go through the array modules fine. Even though the array modules notionally use floating point, and sometimes the value displayed is "NAN" (not a number) you can still send color values through OK. The other problem I was thinking of is with colors in scripts, where you have to extract the color value as floating point, since there is no TColorUsine type available in scripts.
Simon.

[sm_jamieson]

OK, so I realised you just have parameter type ptChooseColor in the module, then send an array to it. I only just realised any parameter type can have an array sent to it - it does not need to be ptArray type !
Simon.

[sm_jamieson]

OK, so what I have previously said is not quite true.

If I connect an array to a ptChooseColor parameter, I can only ever see the first array element, i.e. it does *not* work.

If I connect a color picker output to an array get/set module fader input, and connect the array module output to an array input parameter, I get continual MSG_CHANGE callbacks in the module. Some sort of error must have occurred that makes this happen.

So as far as I can see, although there are SDK routines sdkGetEvtArrayColor() and sdkSetEvtArrayColor(), there is no corresponding parameter type, e.g. ptColorChooserArray, that enables this to work. When connecting color values to floating point parameters there is some type of type incompatibilty that results, which means things go wrong.
This is really the same problem as seen in scripts, where you have to extract a colour value using floating point routines.

Simon.

[sm_jamieson]

Well the basic problem is that TColorUsine is 32 bits unsigned value, stored in 8 bit fields as alpha,red,green,blue.
Usine arrays and most internal storage is in 32 bit floating point values, which are actually 24 bits precision. So it is the alpha field that makes the color numbers too large to be acurately stored as 32 bit floating point values. If you strip the alpha field off, convert to floating point, the add the alpha field back on at the other end (for example assuming always full saturation), it all works fine.
The question is, how do the color parameters work then? The value cannot be stored in 32 bit float, so perhaps internally in Usine, it is converted to another form, split into ARGB for example.
But it is strange that the SDK defines sdkGetEvtArrayColor() and sdkSetEvtArrayColor() when there is no way they can work properly, since an array is an array of floats ! Or perhaps originally Usine did not include the Alpha field so the color values were all small enough ...
Simon.

[23fx23]

i don't remember exactly & might be wrong but i think i'ts used when you make for exemple an array of Tparameter wich are PtChooseColor type.

[senso]

You're right, Color Array flow type is not yet available in the SDK.
This procedure is useless actually because the max length of a TcolorArray flow is 1...
It's just to anticipate future versions.