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

Stefan Kost ensonic at hora-obscura.de
Tue Mar 8 07:53:10 CET 2005


Hi Steve,

good idea! this sounds like a clean solution. it reduces the problem to mark 
gobject parameters to be shared across instances (global settings) or to be 
individual for each polyphonic instance.

So what we need for the gobject properties is a type-flag:
* static
   long term setting, should not be controlled realtime (e.g. vioa envelopes)
   example would be something like ozscilator_table_size
* dynamic_global
   setting that can be controlled, but will be shared across instrument instances
* dynamic_voice
   setting that can be controlled too, but will be individual for each 
polyphonic instance

If we extend the base class anyway to have the gstenvelope/gstcontroller 
instance, can't we also add an array that for each gobject property carries the 
additional flags and a method that can query them:

GstElementPropertyFlags gst_element_get_propery_flags(GstElement *element,gchar 
*property_name);

I have a bad feeling using own flags for the paramspecs as I don't know how to 
handle collisions (e.g. an application defining own flags on the base of 
G_PARAM_USER_SHIFT as well).

Ciao
   Stefan

Steve Baker wrote:
> The best way to implement polyphonic elements might be to do the following:
> - create a monophonic element with whatever behaviours and dynamic parameters
> - create a polyphonic bin element which creates a pool of X number of
> monophonics elements and mixes the results into a single src pad
> - when you want to play a note, iterate over the monophonic elements until
> you find one that is not making noise, then set its parameters to play
> 
> Then the problem of adding/removing object properties goes away. You could
> also do very clever things within the bin such as having each monophonic
> element being attached to its own chain of effects before being mixed
> together.
> 
> cheers
> 
> 
>>Hi Edward,
>>
>>the biggest conceptional problem is currently have is that in my last
>>mail in the thread - multiple voices.
>>There is currently a thread in the glib list about dynamically
>>adding/removing object properties.
>>And one thing they brought to my attention is that gobject prooperties
>>are installed class wide.
>>The number of voice an plugin supports is a property of the instance
>>though.
>>With current dparams and with the control pad approach, it would be
>>possible to do it as these act on a object instance.
>>
>>I have no good idea yet how to do this, when using gobject properties.
>>
>>a.) allocating e.g. 10 sets of parameters and keeping a number of
>>'voices used'.
>>requires to use a GInterface, that tells about the special property to
>>use to control the number of voices.
>>
>>b.) setting a current-voice property first and use this when the voice
>>properties are addressed
>>switch (property_id) {
>>  PROP_VOICE:
>>    current_voice=g_value_get_long(value);
>>    break;
>>  PROP_NOTE:
>>    note[current_voice]=g_value_get_long(value);
>>    break;
>>}
>>Bahhh, wouldn't work nicely with the envelopes ...
>>
>>Stefan
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>gstreamer-devel mailing list
>>gstreamer-devel at lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>>
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel





More information about the gstreamer-devel mailing list