[gst-devel] State of DParams
kost at imn.htwk-leipzig.de
Tue Dec 21 03:56:09 CET 2004
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).
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
Steve Baker wrote:
> On Sat, 2004-12-18 at 13:34 +0100, Stefan Kost wrote:
>>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.
>>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
> - 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.
> 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.
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
\|/ 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
===-=-=--=---=---------------------------------- - - - - -
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 345 bytes
Desc: not available
More information about the gstreamer-devel