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

[Stefan Kost]

Hi Edward,

I cut the reply into pieces, so its easier to follow:


>>== 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.
>  
>
GstEnvelope *gst_element_envelope_add(...);

Finally I seem to understand how this part works, which makes the two 
questions below obsolete!
Adding a propertyiy that already is under control can just be a NOP.

>>=== 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.
>  
>

So this is fine.

Stefan