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

[Steve B. <st...@st...>]

>> 2. stop referring to dparams and start talking about control pads. These
>> are element pads just like any other whose buffer values contain
>> timestamped parameter control information
> I belive we need a test case before, that asserts, that it is no problem
> of
> feeding about 10 to 50 control pads into an audio generator.
>

It would be nice to get some kind of indication from Wim or someone
familiar with 0.9 that this will be possible and the best way for an
element to implement multiple control pads.

All elements with control pads may need to be reimplemented as loop
elements. I'm not even sure there is still a get/chain/loop distinction in
0.9 anymore.

> Another confusing aspect of using control pads is imho, that source
> elements
> like sinesrc are not sources than anymore, because they have input.
> So e.g. in the registry would they still be registered as a source.
> An application needs some wahy to distinguish as source (from the audio
> view
> point) from a source that produces control data.
>

I imagine this would be done by looking at what class/category the element
is in and what mime types it has on src and sinks - which is how things
work now.

> If we use controlpads, what will we use for the mime type?
> control/x-raw-int
> control/x-raw-float

Something like that. And maybe other mimetypes for strings and structured
data like midi.

cheers