> Why did you do this? You are effectively changing the frei0r API while
> perhaps shoe-horning it into a string parameter to keep it ABI
> compatible. IOW, you are imposing that all apps that want to use these
> plugins understand your string syntax and the disguised parameters
> within. You should have discussed it before forging ahead and making
> plugins that use it.

I was unable to to predict any opposition for it. Frei0r accepts
string parameters; I'm using string parameters to provide new
important functionality for all open video applications. I considered
these utilities, not an API change. As an application developer I'm
already providing strings in all kinds of obscure formats, this is
just one more string format for me to use. All other application
developers are essentially in the same boat.

I may have been wrong. If i understand correctly your problem with
this mainly stems from the fact that geometry is provided in a
slightly different way from MLT. For example MLT wants "x/y:...."
for and these plugins want "x:y:...." which will be inconsistent for
MLT users.

> And if MLT is doing this for your app already,
> why are you doing it here? MLT already parses time-based geometry,
> does the interpolation, and sets each frei0r parameter prior to
> processing each video frame. All a frei0r plugin author needs to do is
> to make sure its parameters are mutable.

Is there some example of how this is done? I was unaware of any Frei0r
plugins with keyframed parameters in existence. Had I known of one, I
would definitely tried to use the available mechanisms.

I have zero interest in frei0r_multivalue.h in and of itself. I just
want the functionality provided by "cairoaffineblend" and "cairoblend"
and I want it...yesterday.

I really find it unacceptable that users of Flowblade (or any other
open video editor) can't do composited images with rotations and
variable mix levels for other blend modes than Normal (using a single
point of control at least, it may be possible in some complicated way
that I'm not aware of or interested in).

So to move forward here we have some options :

1) Fix these to use the mechanisms you describe above. I'm going to
need some reference code to see how it is done, I do not know how to
achieve this with the current information I have, but for my part I'll
try to look at Frei0r code once more.

2) Agree on some other mechanism to provide Frei0r plugins with
keyframed parameters. I'm perfectly willing to use any other
solution, but I would really appreciate if people demanding this would
provide the second solution themselves.

3) Fix frei0r_multivalue.h to accept MLT style geometry input.

Dan, comments?