[gst-devel] State of DParams

[Steve Baker]

The conversion to a DParams property is not automatic. It requires code
changes within the element. So you can implement whatever policy you need,
just like you do now with properties.

> Hi Steve,
>
> one more comment. If your approach turns normal GObject properties into
DParams,
> how does an element controls the changing policy. Imaging an element
having a
> quality switch and a few other properties. The quality can't be changed
when in
> playing mode (as e.g. this would need to reconfigure some
lookup-tables). Suggestions:
> a.) elements just ignore such changes when they happen, and only evalue the
> property value when going to play-state next time
> b.) we add an interface to publish such policies
>
> Ciao
>   Stefan
>
> Steve Baker wrote:
>> 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
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real
users. Discover which products truly live up to the hype. Start reading
now. http://productguide.itmanagersjournal.com/
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>
> --
>       \|/            Stefan Kost
>      <@ @>           private            business
> +-oOO-(_)-OOo------------------------------------------------------ - -
- -   -
> |       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach
301166
> |      ///           04277 Leipzig      04251 Leipzig
> | __  ///            Germany            Germany
> | \\\///    Phone    +49341 2253538     +49341 30766101
> |  \__/     EMail    st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de |   
       WWW      www.sonicpulse.de
> www.imn.htwk-leipzig.de/~kost/about.html
> ===-=-=--=---=---------------------------------- - - -  -    -
>