> We have made an exception for the curves filter's bezier spline and
> the OpenCV filters' classifiers because there was not an adequate way
> to do it otherwise.

Why is "curves" using bezier spline instead of Catmull-Rom spline,
which is industry standard for curves (Gimp, Photoshop, After
Effects...) and a lot less twitchy? Open Kdenlive and Gimp side by
side and do some curves manipulations and you'll see what I mean. Does
anyone have any objections for me creating a filter called "crcurves"
to provide a Catmull-Rom based curves implementation?

> It already works for all frei0r double params within MLT and has for a
> long time. The MLT-frei0r filter bridge is currently using
> mlt_geometry to accomplish this, but only using the x field of it.
> Thus, any f0r_param_double (or f0r_param_bool) can be animated in a
> mlt_property with something like: 0=0.01; 50=0.1; 100=0.5; 500=1.0.
> Kdenlive has been taking advantage of this capability for a while.

So that happens fully on application/MLT side then. Kdenlive sets "x"
MLT property value to "0=0.01; 50=0.1" and MLT sets Freior "x" param
values per frame. Plugin knows nothing of any of this happening, and
just uses value of x?

> Sorry, but you need to get rid of frei0r_multivalue.h and make
> discreet parameters.

So in case of "cairoblend" I'll go from current:

   typedef struct cairo_blend_instance
  {
     unsigned int width;
     unsigned int height;
     char *opacity;
     char *blend_mode;
   } cairo_blend_instance_t;

to:

   typedef struct cairo_blend_instance
   {
     unsigned int width;
     unsigned int height;
     double opacity; //  this is now F0R_PARAM_DOUBLE;
     char *blend_mode;
   } cairo_blend_instance_t;

and just use opacity when drawing:

double frame_opacity = inst->opacity;

and now if i set "opacity" in Flowblade to "0=0.01; 50=0.1" MLT sets
correct value to opacity for each frame?

Is this correct?