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

[Stefan Kost]

Hi Steve,

> ...
> 
> Now that 0.9 is opening I should give my thoughts on where I think dparams
> should go.
I would loved to read your thoughts any earlier ...

> DParams were created to overcome a limitation in GStreamer at
> the time (ie having lots of sink pads on an element). Also it seemed like
> a good idea at the time...
> 
> My understanding is that 0.9 should fix the scheduling issues that make
> lots of sink pads hard so here is what I think we should do in 0.9:
> 
> 1. remove all trace of dparams libraries and usage in 0.9. Make existing
> dparams based elements use only gobject properties (for now)
That just requires removing the dparams code, then they use gobject properties 
as before.
> 
> 2. stop referring to dparams and start talking about control pads. These
> are element pads just like any other whose buffer values contain
> timestamped parameter control information
I belive we need a test case before, that asserts, that it is no problem of 
feeding about 10 to 50 control pads into an audio generator.

Another confusing aspect of using control pads is imho, that source elements 
like sinesrc are not sources than anymore, because they have input.
So e.g. in the registry would they still be registered as a source.
An application needs some wahy to distinguish as source (from the audio view 
point) from a source that produces control data.

If we use controlpads, what will we use for the mime type?
control/x-raw-int
control/x-raw-float
> 
> 3. change some existing elements to expose their parameters as control pads
Some elements should be sinesrc and volume.
> 
> 4. based on the experience of 3. write a little helper library which makes
> adding control pads as easy as possible, doing things like:
>   - making it easy to expose a parameter as a gobject property and/or a
> contrl pad
>   - using the control value with the desired timestamp when processing a
> stream buffer
>   - optimised convenience routines to interpolate values over the duration
> of an audio buffer
That would be the new libcontrol
> 
> 5. write a bunch of elements which produce control data. In order of
> complexity these could include things like:
>   - an element with a gobject property which passes that value to its src pad
       and hold the value as long as there is no new value
     - an element with a gobject property which passes that value to its src pad
       once and resets the value to a default value (needed for triggers)
>   - an element with a bunch of gobject properties which define some kind
> of control curve (LFO)
>   - an element which is passed a GstStructure as a gobject property which
> contains timelined data points. Src pad produces interpolated control
> data.
       Again we need version that interpolate, versions that do not and version 
that handle trigger data.
>   - elements which listen to some kind of external data source (midi, gui,
> network control protocol) and produce non-blocking control data

So here we need a concept that generally handle interpolation and trigger data.

Overlaying data should work. I just describe the scenario here, becuase it took 
we a little thinking wheter this would work or not:
Imagine you have your sequencer running in a loop. It feeds recorded control 
values into the elements. Additionally there is a control GUI open, when the 
user can move sliders etc.
In this case both sources will need to modify the same control-object.
> 
> 6. These control data elements could have an agreed behaviour of never
> blocking. If the source of the control data blocks, the element just
> returns the previous value (or a placeholder event). I don't know if this
> is required in 0.9
   Maybe the can have a behaviour property that decides wheter the return:
   - the default value : trigger
   - the last value : continuos control data
> 
> Doing 1. and a minimal amount of 3. and 5. will get us to where we are now
> with the current dparams implementation, so I think doing this much would
> be feasible for 0.9
> 
> I can't say that I will have time to do any of this. However it would be
> good to get some consensus so that if someone wants to do it then we all
> know exactly what needs to be done.
We already agreed that Eduard and me will take this over, as we just need it.
Anyway we would welcome, if you could help fleshing out the concept.
> 
> Let the lively discourse begin.
Here you are ;)
> 
> cheers
> 
> 
Stefan