[gst-devel] RFC: argument system?

[Steve Baker]

I think that my dynamic parameters implementation could be easily extended
to allow for runtime adding and removing of parameters to match the adding
and removing of pads.  And it could be done with no additional impact on
common-case real-time dynparms performance.

The biggest issue for me would be whether to make the creation of new
dynparms explicit or implicit based on the creation of new pads.

The implicit case might work something like this:
- A dynparm instance is flagged as belonging to all output pads
- when a new output pad is created, the dynparm group creates a new instance
of the dynparm to match it
- apps get notified that there is a new dynparm to create a gui for
- these dynparm instances have an instance name somehow related to the pad
name, the pad number and the dynparm name

This would make for a simple API, but the implementation may be complex and
the element developer wouldn't have much flexibility in behaviour.

I think I favour a more explicit approach, where it is up to the element
developer to write code which creates new dynparms when new pads are added. 

The dynparms group API will have functions to create/destroy dynparms at any
time during runtime - although unless you're writing a variable pads
element, you will only ever need to create dynparms in the initialiser.

cheers

> -----Original Message-----
> From: Erik Walthinsen [mailto:omega at temple-baptist.com]
> Sent: zondag 13 mei 2001 9:30
> To: gstreamer-devel at lists.sourceforge.net
> Subject: [gst-devel] RFC: argument system?
> 
> 
> The current gtk/glib get_arg/set_arg mechanism is functioning 
> OK for us
> right now, but I'm wondering if it will continue to do so.  
> Consider the
> case of a mix matrix.  It'll have REQUEST pads for both input 
> and output,
> and internally it will have a volume level for each input 
> channel going to
> each output channel, or NxM volume knobs, like like an analogue mixer
> board.
> 
> It is unclear to me whether gtk/glib arguments can be added/removed at
> runtime, on a per-object basis.  It doesn't look likely, since the arg
> data is stored in the Class structure.  Also, consider the 
> naming scheme
> for these arguments, not to mention the expense of doing 
> string-matching
> on each.
> 
> It makes me think that we may indeed want to build our own 
> control system
> for elements, but I'm hesitant to do that for quite a number 
> of reasons.
> First of all, the gtk/glib functions already exist, have a number of
> features that are useful for more unusual plugins (see
> http://gstreamer.net/lame-args.png for an example), and is 
> still evolving
> in glib 2.0.
> 
> Then again, we may want to consider that there are different 
> classes of
> controls for different classes of elements.  It could be that 
> we use the
> existing gtk/glib system for common arguments like those 
> found in lame,
> but our own system for things like mix levels, etc.  
> Basically anything
> that could be changed frequently, even the existance of a 
> given argument
> is dynamic itself.
> 
> steveb's dynparms proposal may be the right way to go about this,
> especially if it can be done efficiently and without 
> significant code in
> the common case (that is, less frequent changes that are still
> time-critical).  If it's designed to be efficient at *both* dynamic
> dimensions somehow, it would be ideal.