On Sun, Nov 25, 2012 at 9:12 PM, Janne Liljeblad
<janne.liljeblad@???> wrote:
>> 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

MLT already provides the time-based stuff, and things like x, y,
width, height, mix, and rotation belong as separate frei0r parameters.

> 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.

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.

> 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.

MLT does not care if it is / or :. It only gives significance to
semi-colon, equal sign, and the radix character of LC_NUMERIC.
Anything else non-numeric is a delimiter.

>> 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.

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.

(It is already high on my TODO list to move this capability of
mlt_geometry into mlt_properties to generalize it properly, but frei0r
plugins are not dependent upon that work.)

> 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.

Instead of looking up the parameter value for a given time, trust that
the application has changed the parameter value for you. Pretty much
100% of the frei0r source code is a reference here.

> 2) Agree on some other mechanism to provide Frei0r plugins with
> keyframed parameters. I'm perfectly willing to use any other

It is not necessary; MLT already drives the parameters over time.
Think about it this way. The original use case of frei0r was for VJ
apps where people twiddle knobs. The filters generally have to react
in realtime to those changes.

> 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?

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

--
+-DRD-+