[gst-devel] discussion about dparams

[Steve Baker]

Hi Steve,
> Hi Steve,
>>>hi steve,

> I volunteer to help testing and documenting ;-)

thanks

>> Element API:
>> - Makes extensive use of GstStructures to define dparam behaviour
>> - Dparam instance behaviour can be specified in gst-launch, making demos
>> so cool that wingo will want to use dparams ;)
>> - Can easily turn any existing element property into a dparam (optional
>> at
>> runtime)
>> - Audio buffers can be altered with smooth interpolation by creating a
>> control array which has the same number of samples as the buffer -
>> instead
>> of using evil macro magic
>> - Dparams can be added and removed at runtime (unlike element
>> properties)
> That is good. We're going to need this.
> Would it make sense to add some param metadata at this level or should
> this go
> to an interface (e.g.
>  that a 'freq' dparam is infact a 'note' or
>  that a dparam is meant to use in a sequecer and not to be set by
>    e.g. a slider (triger type params)
> )

In the dparam descriptors I was going to have a flag for logarithmic
values. I might change this so that there is a list of possible flags -
these could describe what kind of data the param represents. Possible
flags could be:
- logarithmic
- frequency
- amplitude
- discrete (this may be implicit in the fact that the parameter is an int
or an enum)

The dparam descriptors have pretty much the same information as a
GParamSpec plus any extra stuff like these flags, and stored in a
GstStructure. I was going to write a convenience function to convert a
dparam descriptor to a GParamSpec for defining element properties.

A descriptor might look something like this:

freq,
        default = (double) 440.0 ,
        bounds = (double) [10.0, 20000.0] ,
        flags= (string) ["logarithmic", "frequency"] ,
        title = (string) "Frequency" ,
        description = (string) "Frequency of sine wave"


> This included that e.g. for a source we need to know
> which
> dparam is used to trigger a note (so that we can display this dparam as
> keys
> like 'A-4' and not '440 Hz'.

The topic of tuning systems and temprements is *huge* and should probably
be done in a seperate library. If we're going to do this note mapping
properly we probably shouldn't assume Equal Temprement. If the dparams
flags the parameter as a frequency then you can handle the mapping to a
note yourself.

See here re tuning systems:
http://www.midicode.com/tunings/index.shtml

> Another thing is voices (you've already hit that). For a sound generator
> is is
> quite obvious what that means. You can trigger multiple notes in one
> instance.
> The separation of global and voice data means, that one would like to set
> things
> like envelopes globaly for the instance, but for each voice set e.g. note
> and
> volume. Like sketched in the interfaces document, this can be done with an
> interface. The only thing I am not happy with is using dparam names like
> "note_XXX" with "XXX" denoting the voice.

OK, so global data are just element properties with dparams attached.

Voice data might have to be named like note_XXX but we could make it
easier to handle this by making the dparam descriptors look something
like:

freq_%d,
        default = (double) 440.0 ,
        bounds = (double) [10.0, 20000.0] ,
        flags= (string) ["logarithmic", "frequency"] ,
        title = (string) "Frequency" ,
        description = (string) "Frequency of sine wave",
        instances = (int) 4

would define dparams freq_0 to freq_3. This is how sometimes pads work too.

cheers