Re: [gst-devel] State of DParams

[Stefan K. <ko...@im...>]

Hi Steve,

a few more thought for the redesign.

The GstDParam class has a 'value-changed' event, but the 'notify::value-xxx'
seems to be not working. I was hoping to listen to notifies to update the UI,
but I don't receive any.
I don't know if it is worth to fix it in the current code ...

Generally as e.g. sinesrc and volume only expose some of their properties as
dparams, a change of the dparams should also relflect in a change of their
gobject properties.

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
> gst...@li...
> 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
===-=-=--=---=---------------------------------- - - -  -    -