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

[Steve Baker]

Thomas surmised
> Hi gang,
>
> here's a quick recap of some of the things we've discussed and decided
> on during this summit.
...
> - dparams (Stefan/Edward)
...

Now that 0.9 is opening I should give my thoughts on where I think dparams
should go. 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)

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

3. change some existing elements to expose their parameters as control pads

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

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
  - 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.
  - elements which listen to some kind of external data source (midi, gui,
network control protocol) and produce non-blocking control data

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

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.

Let the lively discourse begin.

cheers