[gst-devel] new gst element interfaces

[ensonic]

hi,

I've just posted two interface proposals under:
http://bugzilla.gnome.org/show_bug.cgi?id=396774
http://bugzilla.gnome.org/show_bug.cgi?id=396779

They are about tha help url and a preset interface. Please post your
comments there. I also have more interface in buzztard projects cvs:

One is a tempo iface:
http://buzztard.cvs.sourceforge.net/buzztard/gst-buzztard/src/tempo/
This basically adds three iface properties together with a method to
atomically set the tempo. This is interesting for music to allow effects to
sync with the tempo, e.g. in an echo effect the user can specify the delay
as a fraction in relation to the tempo to get rhythmic echos. The advantage
of using the iface is that the tempo data is available right away. Using a
tag for the bpm would be an alternative. We would need a new tag for the
BPM (see http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:ID3_Tag_Mapping) and others. The elements need to use a default setting to calculate their internal parameters anyway, as hosts like gst-launch don't use the tempo iface.

The second is the propertymeta iface:
http://buzztard.cvs.sourceforge.net/buzztard/gst-buzztard/src/propertymeta/
This is a kludge right now. There are several additional metadata on
gobject properties that would be usefuly. The iface basicaly 'standartizes'
quarks to attach them as qdata. It would be good to get a list of what
things other apps need to get this into shape. Things from my list are:
* mark properties as editable: otherwise we don't show them in a generated ui
* mark properties as triggers: imho very audio specific, triggers are
keyborad notes or drum triggers, that when set triger some processing, they
need special handing for the controller (they don't get continous changes)
and it is useful for hosts to figure out which of the properties is the
trigger. I am not sure if this better gets done by using new paramspecs.

Thats it for now. lets your comments come and thanks for listening.

Stefan