[gst-devel] dparam -> controller merge plan

Stefan Kost ensonic at hora-obscura.de
Mon Aug 1 07:59:02 CEST 2005


right now I have a dparam-less version here. So the next step is to move the 
gst-controller from gst-sandbox to gstreamer/libs/gs/controller. This includes 
docs and so on.

Then plugins can be controller-ized. I'll do sine, volume and ladspa which where 
using dparams before. Would be cool if someone else does one or two plugins so 
that we see if the api is good.

Now some open questions about the controller implementation. The aim was being 
most unobtrusive. Thus for plugins the required changes are minimal. A major 
difference to dparams is that the controller uses the same object-properties. 
Plugin authors just give some more meta data, so that apps can find out for 
which properties it makes sense to bind a controller to.
Right now we introduce a new GParamSpecFlag GST_PARAM_CONTROLLABLE.

Beside this some other flagging is needed. E.g. trigger params, like a 
musical-note or a drum-pad trigger are require special treatment. Unlike a 
volume parameter, these are only valid for exactly one time stamp. Now the 
controller has modular function to handle properties. There are functions for 
interpolation and also to handle triggers. Problem is that the app needs to make 
the choice. So another GParamSpecFlag would be useful (GST_PARAM_TRIGGER).

Unfortunately I lost my crystal sphere and so I can foresee how many more flags 
we need. I welcome any feedback, whether I should just add another flag or go an 
alternative path. I recently discovered that GParamSpecs have a qdata hash. 
Hence we can add meta data there. The gst-controller would just export the 
GQuarks (keys to the qdata hash). This way we avoid running out of flag-bits.
There are no performance concerns with that as the flag ist not queried during 
critical ops, just at the init phase.

Apart, I welcome anyone looking at the source and giving comments.



PS.: I already know that I have difference tabs/space settings among all the 
computers I work on and that the source might look a bit odd for just. This will 
be fixed by commiting to HEAD with the aid of gst-indent ;)

More information about the gstreamer-devel mailing list