[gst-devel] discussion about dparams

[Stefan Kost]

Hi Steve,

<snip>
> 
> 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)
note is somewhat special. marking it as a frequency is not enough, as e.g. an
instruments can have 3 dparams all using frequencies, one is for the note, but
the other two are used as an LFO. An application would like to find out about this.
> 
> 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"
> 
That looks good.
> 
> 
>>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
> 
agree fully here.
> 
>>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.
>
The buzz music software that we try to follow loosly defines three kinds of darams:
attributes : that maps to gobject properties (one would use it for thats that
nearly never change)
global params : maps to dparams (every instance of the plugin has one set of
them, e.g. describing sound synthesis params. Still these params can change in
realtime).
voice params (or track params): map to dparams as well (a small set of params
that exist a multiple times).
> 
> 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.
Oh yes, that is a good comparission.

Btw.: when rewriting the library can we look for a new namespace. the
data-protocol already uses "dp_". So we may use "dparam_" or "dynpar_".

Ciao
  Stefan
-- 
      \|/            Stefan Kost
     <@ @>           private            business
+-oOO-(_)-OOo------------------------------------------------------ - - -  -   -
|       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach 301166
|      ///           04277 Leipzig      04251 Leipzig
| __  ///            Germany            Germany
| \\\///    Phone    +49341 2253538     +49341 30766101
|  \__/     EMail    st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de
|           WWW      www.sonicpulse.de  www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kost.vcf
Type: text/x-vcard
Size: 345 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20040723/35a946c7/attachment.vcf>