2011-12-25 19:49:41 +00:00
|
|
|
Controller
|
|
|
|
|
----------
|
|
|
|
|
|
|
|
|
|
The controller subsystem allows to automate element property changes. It works
|
|
|
|
|
so that all parameter changes are time based and elements request property
|
|
|
|
|
updates at processing time.
|
|
|
|
|
|
|
|
|
|
Element view
|
|
|
|
|
~~~~~~~~~~~~
|
|
|
|
|
Elements don't need to do much. They need to:
|
|
|
|
|
- mark object properties that can be changed while processing with
|
|
|
|
|
GST_PARAM_CONTROLLABLE
|
|
|
|
|
- call gst_object_sync_values (self, timestamp) in the processing function
|
|
|
|
|
before accessing the parameters.
|
2012-01-01 19:59:22 +00:00
|
|
|
|
2013-03-08 12:15:32 +00:00
|
|
|
All ordered property types can be automated (int, double, boolean, enum). Other
|
|
|
|
|
property types can be automates as well by using special control bindings. One can
|
|
|
|
|
e.g. write a control-binding that updates a text property based on timestamps.
|
2011-12-25 19:49:41 +00:00
|
|
|
|
|
|
|
|
Application view
|
|
|
|
|
~~~~~~~~~~~~~~~~
|
2012-01-01 19:59:22 +00:00
|
|
|
Applications need to setup the property automation. For that they need to create
|
2011-12-25 19:49:41 +00:00
|
|
|
a GstControlSource and attach it to a property using GstControlBinding. Various
|
2012-01-01 19:59:22 +00:00
|
|
|
control-sources and control-bindings exist. All control sources produce control
|
2011-12-25 19:49:41 +00:00
|
|
|
value sequences in the form of gdouble values. The control bindings map them to
|
|
|
|
|
the value range and type of the bound property.
|
|
|
|
|
|
2012-01-01 19:59:22 +00:00
|
|
|
One control-source can be attached to one or more properties at the same time.
|
|
|
|
|
If it is attached multiple times, then each control-binding will scale and
|
|
|
|
|
convert the control values to the target property type and range.
|
|
|
|
|
|
|
|
|
|
One can create complex control-curves by using a GstInterpolationControlSource.
|
|
|
|
|
This allows the classic user editable control-curve (often seen in audio/video
|
|
|
|
|
editors). Another way is to use computed control curves. GstLFOControlSource can
|
|
|
|
|
generate various repetitive signals. Those can be made more complex by chaining
|
|
|
|
|
the control sources. One can attach another control-source to e.g. modulate the
|
|
|
|
|
frequency of the first GstLFOControlSource.
|
|
|
|
|
|
2012-01-23 10:02:45 +00:00
|
|
|
In most cases GstControlBindingDirect will be the binding to be used. Other
|
|
|
|
|
control bindings are there to handle special cases, such as having 1-4 control-
|
|
|
|
|
sources and combine their values into a single guint to control a rgba-color
|
2013-03-08 12:15:32 +00:00
|
|
|
property.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TODO
|
|
|
|
|
~~~~
|
|
|
|
|
control-source value ranges
|
|
|
|
|
- control sources should ideally emit values between [0.0 and 1.0]
|
|
|
|
|
- right now lfo-control-sources emits values between [-1.0 and 1.0]
|
|
|
|
|
- we can make control-sources announce that or fix it in a lfo2-control-source
|
|
|
|
|
|
|
|
|
|
ranged-control-binding
|
|
|
|
|
- it might be a nice thing to have a control-binding that has scale and offset
|
|
|
|
|
properties
|
|
|
|
|
- when attaching a contro-source to e.g. volume one needs to be aware that the values
|
|
|
|
|
go from [0.0 to 4.0]
|
|
|
|
|
- we can also have a "mapping-mode"={AS_IS, TRANSFORMED} on direct-control-binding
|
|
|
|
|
and two extra properties that are used in TRANSFORMED mode
|
|
|
|
|
|
|
|
|
|
control-setup descriptions
|
|
|
|
|
- it would be nice to have a way to parse a textual control-setup description. This
|
|
|
|
|
could be used in gst-launch and in presets. It needs to be complemented with a
|
|
|
|
|
formatter (for the preset storage or e.g. for debug logging).
|
|
|
|
|
- this could be function-style:
|
|
|
|
|
direct(control-source=lfo(waveform='sine',offset=0.5))
|
|
|
|
|
or gst-launch style (looks weird)
|
|
|
|
|
lfo wave=sine offset=0.5 ! direct .control-source
|
