Fwd: [gst-devel] Re: dparams roadmap (AKA dparams are dead, long live control pads)

[Steve Baker]

>> There should be some other interpolate methods:
>> - trigger (already mentioned by Stefan, should also handle string
>> values)
>> - square (to handle logarithmic values)
>> - inverse square
>> - sine
>> These last three are implemented by Parameter Curves in DirectX Media
>> Objects
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dmo/htm/parametercurves.asp
>
>   Agreed those are interesting interpolation methods, but we first
> need to get the basic interpolations working (Trigger, linear, square
> (what I called quadratic), cubic). All those interpolations only need
> TimedValues (no extra parameters per point).

I don't think the Parameter Curves need any extra parameters per point. It
does have a different approach though - each curve has an explicit start
and end point, so you say you want to go from A to B with curve X.  If we
went in this direction it wouldn't be the first time GStreamer got ideas
from MS ;)

>> There might be some other ideas in Parameter Curves worth incorporating.
>> Maybe the best idea is to make the interpolate mode per GstTimedValue
>>  instead of per GstEnvelopedProperty. This gives a lot more flexibility
>> in
>> how the curves are defined:
>> typedef struct _GstTimedValue
>> {
>>   GstClockTime time;
>>   GValue *value;
>>   GstInterpolateMode interpolation;        // Interpolation mode
>> } GstTimedValue;
>
>   This seems to be an overkill way of doing things. Most people will
> be using the same interpolation method all the time.
>   Also changing interpolation method for a property would mean having
> to change the interpolation variable for all timedvalues.
>   And how would you decide how to do the interpolation between two
> points that have different interpolation methods. For example: Point A
> (linear interpolation) and point B (cubic interpolation) ?

I guess we'd have to do it the same way as Parameter Curves - explicitly
defining a start and end point with the curve type.

Where I'd like to end up is to allow applications to define complex curves
with high-level gui handles. I was angling to get dparams to handle this
directly but if it provided flexible enough primitives then any
higer-level curve behaviour could be build on top of it. I think the
current proposal could do this but it is still useful to explore the
options.

>> So is it possible to extend the behaviour of GstEnvelope? If so would it
>> be by subclassing GstEnvelope or by adding hooks to add more
>> interpolation
>> modes?
>
>   One way I see of doing this would be to:
>   * make GstEnvelopedProperty handle the list of TimedValues,
>   * have the interpolation methods mentionned above as structures of
> function pointers (hooks) that are automatically selected when
> changing the interpolation method. The content of that structure is
> public.
>   * Add an extra function for selecting interpolation where the user
> can specify a function pointers structure of his choice (and that
> automatically sets the interpolation to GST_INTERPOLATE_USER).
>   * Allow the user to create "derivates" of the GstTimedValue (à la
> GObject). Ex : typedef struct {GstTimedValue value; gboolean
> extra_flag} GstTimedValueMyInterpolation;

Instead of "derivates" of the GstTimedValue it might be enough to have a
private pointer in GstTimedValue which allows an interpolate method to
store anything it needs in each point.

cheers