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

[Edward Hervey]

Hi again, this time from Paris :)


On Wed, 23 Feb 2005 19:28:00 +0100, Stefan Kost <ensonic at hora-obscura.de> wrote:
> Hi Edward and others,
> 
> the reason to name the thing GstEnvelope is quite obvious, when thinking
> about a timeline and smoothed control values on it.
> When looking on the purpose, that it offers a convinient way to control
> elements, I would rather prefer GstController.

  No problem against that.

> 
> == Now some nitpicking about the naming:
> 
> GstEnvelope *gst_envelope_properties (...);
> GstEnvelope *gst_element_envelope_properties (...);
> 
> should be something like
> GstEnvelope *gst_envelope_new(...);
> GstEnvelope *gst_element_new_envelope(...); // not sure about this one

  no problem for the first one, but the second one should maybe be
gst_element_envelope() since it's not automatically a "new" envelope.

> 
> Question here is, what does the first, if the object already has an envelope attached to these properties?

  The trick is that the first function only finds out what the given
properties GParamSpec are (in order to know the type of the given
properties). The GstEnvelope doesn't know/remember what GObject it is
attached to. BUT (and that would involve a minor addition to
GstElement), the GstElement would have an "envelope" property which by
default would be NULL. The second function checks if the GstElement
has a set envelope and if so uses that one, else it creates one (with
the first function) and sets that on the given GstElement.

> 
> == Again some naming:
> 
> gboolean gst_unenvelope_properties (...);
> gboolean gst_element_unenvelope_properties (...);
> 
> should be called
> 
> gboolean gst_envelope_detach (...);
> gboolean gst_element_detach_envelope (...);
> 
> == Does adding:
> 
> gst_element_get/get_envelope();
> 
> means
> 
> g_object_get(element,"envelope",&envelope,NULL);
> 
> won't work? The only reason for this deviation from gobject style I see is to avoid this property beeing used together with an envelope. But thats easy to avoid (GObject derived properties wont IMHO make sense to be controlled).

  In fact the g_object_get(..) would work but only for GstElement (see above).

> 
> == Removing envelope points
> 
> gboolean gst_envelope_set (...);
> gboolean gst_envelope_set_many (...);
> 
> can be used to add control changes at given timestamps.
> We also need API to remove single control changes (imagine you cut a piece of video/audio from the timeline, one won't need the envelope there):
> 
> gboolean gst_envelope_remove (...);
> gboolean gst_envelope_remove_many (...);

  I agree on the principle, it should be allowed although it's just to
clean up data that wouldn't be used anyway. This makes me think that
maybe we should need a way to reset all values for an "enveloped"
property, something like :

  gboolean gst_envelope_reset_property (GstEnvelope*, gchar*);

> 
> == More nit picking:
> 
> When naming things 'property_name', we should name 'timedvalues'
> 'timed_values'.
> 
> == GstValueArray;
> 
> shouldn't there be
> 
> gst_value_array_new();
> gst_value_array_free();
> 
> methods? To me it sounds better to keep the internals hidden.

  The GstValueArray is nothing internal. It's content are know (and
definitely used) by both the application and the plugins. I'd agree on
adding those functions just for the sake of simplifying their use.

> 
> == Current conclusion ;)
> 
> I belive it does much more that I need. Things that I personally find a
> bit complex are:
> 
> === attaching multiple envelopes to one property
>   are they added and clipped or mixed?
>   what happens to envelopes controlling an enum property then?

  You can't add multiple envelopes to one property. A GstElement can
only have one GstEnvelope, and a GstEnvelope can only have one
property per given property_name.

> 
> === attaching one envelope to multiple properties
>   yes synthesizer do that, it called a modulation matrix there.
>   the difference is that for each target one would like to set a weight
> (percentage of influence)

  I couldn't find how to do that. But nothing stops setting the same
timed_value on different GstEnvelope'd properties.

> 
> == Finally:
> Where will we put it - gst-core/libs/gst ?
> How will we name it - libgstcontroller ?

  I'm ok with naming it libgstcontroller. As to where to put it... no clue.

> 
> Ciao
>   Stefan
> 

A piu tarde,
   Bilbo