[gst-devel] dparam -> controller merge plan
Stefan Kost
ensonic at hora-obscura.de
Mon Aug 1 07:59:02 CEST 2005
hi,
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.
Thanks,
Stefan
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