[gst-devel] State of DParams

[Steve Baker]

On Sat, 2004-12-18 at 13:34 +0100, Stefan Kost wrote:
> hi all,
> 
> a few month agao there was a discussion about the current DParams
> implementation. Steve Bakker was planing to submit some note about changes he
> would like to do. This unfortunately not yet happend.
> A few days ago I asked him, if he could at least please outline what he dislike
> about the current implementation and what he would like to change.
> I've not yet received an answer.
> 
> The problem is that the buzztard-project is needing a mechanism like DParams.
> We now have a student as a new project member who would like to develop a simple
> synthesizer plugin. He needs some fedback on DParams as well.
> 
> We've tried to hold back any serious usage of that feature as long as we can.
> Right now current DParams can easilly be deprecated as noone is using them apart
> the sinesrc, ladspa, volume plugins.
> 
> So if anyone can say something to this issue, it would be kind to do it now.
> 
> Stefan
> 
> PS.: Steve, please do be upset that I now posted this public, if you cant handle
> it right now, please tell us.

I'd rather have this discussion on the list anyway. You posted to me
these questions:
> Now the question is what is the state of your dparms rethinking?
> Some question to that:
> #1) What is it that you think is bad about the current desing?

A few things including:
- the lib shouldn't be in core gstreamer
- the dparams objects are too heavy-weight - they don't need to be
gobjects
- there is no real need for the sample processing loop in the element to
be so complex but dparams currently requires it to be, and does naughty
things like macros with side-effects
- its always been half-finished and little used

> #2) What about using ordinary gobject-properties and let the plugin
listen to notify::property events (this can't do timelined params,
timestampled > params etc.)

The options now for controlling parameters in elements are gobject
properties or pads which take control values. props are trivial but you
don't have much control over exactly when the value gets updated.
Control pads will give you timestamped updates but requires more code
and complexity.

My still-half-finished redesign of dparams addresses the above problems
and is designed to integrate with either a props approach or a control
pad approach (or a custom approach based on interfaces for example). I
can't give any indication of when the redesign will be ready so you
shouldn't rely on it for buzztard. If using gobject-properties meets
your needs for now then go for it.

If/when the redesign is ready you will be able to do the following. Say
you have an element which has a gobject property which controls the
amplitude of a sound. If that element was given dparams support you
could attach behaviours to that property by assigning a GstStructure to
the element.

As an example the gobject property could become the centre-value for a
sinewave LFO. Other values in the GstStructure would specify the LFO
amplitude and frequency and each of these values could themselves be
assigned dparams behaviours. So you end up with a chain of unit
functions which can define a complex pattern for the control value for
any given timestamp.

So anyway, I apologise if I gave you the expectation that the redesign
would be ready for buzztard. Let me know what you end up doing - I might
be able to give some useful feedback.

cheers