Access alpha

[spxl]

The new FF_TYPE_x defines in freeframe.h added by Resolume...

// Added by Resolume for HSB colors
#define FF_TYPE_HUE 200
#define FF_TYPE_SATURATION 201
#define FF_TYPE_BRIGHTNESS 202

..can be used to make Resolume use the v6 colour widget, which is neat.

However, it doesn't seem possible to access the value of the alpha slider that appears in the colour widget, which is not so neat.

Can we get/use an additional define for the alpha slider?

#define FF_TYPE_ALPHA 203

I have made a plugin that uses alpha values, and the current kludge is to have the hue, saturation, brightness sliders which result in the displaying v6 colour widget, only the alpha sliders don't do anything, and having a separate FF_TYPE_STANDARD slider for the alpha value. It works, but is confusing and ugly, especially as I have three colours to choose for the one plugin.

[smokris]

The FreeFrame 1.5 spec defines an alpha parameter type:

value = 11
type = alpha
Transparency value esp. for use in a 3 colour colourpicker + alpha

That value appears in the FFGL trunk header, but not in the FFGL 1.6 branch header.

(Also there's a conflict between that and FF_TYPE_OPTION = 11 defined in Resolume's fork.)

[spxl]

I think I may have previously tried using FF_TYPE_ALPHA, which didn't work, but my memory is hazy!

In any case, using type = 11 doesn't work.

[smokris]

In any case, using type = 11 doesn't work.

Same here; in Resolume Avenue and Arena, type=11 doesn't show any widget. Some other hosts (such as VDMX and MMV) show a standard float widget for type=11.

[jorisdejong]

As far as I can see, there is no other mention of type=11 being reserved for Option type before we published our fork to Github. Judging by 56b3fa2, it wasn't properly implemented either until we pushed the FFGL2.0 spec. This makes chances of anyone using it right now pretty slim.

All in all, it sounds like we should keep type=11 reserved for Alpha (to not break compatibility with VDMX and Magic), and change the type reserved for Option.

Once we make that change, we can then make Resolume take type=11 as the fourth parameter of
a color picker widget.

[ResolumeMenno]

I would argue that we should keep 11 as option. Color picker based support for alpha should then use type 203 as suggested by spxl.
We've already broken vdmx/magic compatibility by changing the init function. They already need to update their hosts to the new ffgl headers, so then a change in the number associated with the param types will be adopted right away.
If we change 11 back to alpha and use 13 as option then everyone who has already updated their plugin to ffgl 2.1 would need to recompile and we may get a version mismatch between those plugins and resolumes beta build that supports ffgl 2.1

[MennoVink]

It seems like this may have been an issue on the host side. I've updated the Gradient example and tested with Resolume 7.3.0 and there it works as intended.