[gst-devel] discussion about dparams

[Stefan Kost]

Hi Steve,

>>hi steve,
>>
>>I hold my promisse and bug you further, but now public.
>>For the software we develop (buzztard.sf.net) we need a machanism like
>>dparam
>>(we actually use them). I commited some thoughts to
>>docs/random/ensonic/dparams.
>>What you and otheres think - shall we extend them or should we follow a
>>different way?
> 
> 
> Apart from the last point "* concept for global, voice params" these
> points seem to be minor tidying up.
> 
> I've actually just started rewriting the dparams library to remove much of
> the suckage and make it easier to use and extend.
>
I volunteer to help testing and documenting ;-)

> This is all a bit inconvenient for you since you've just started using
> them ;)
> 
we are still very early in development, so it will be possible to move to a
different implementation.
>
> I'll commit docs/random/steveb/dparams in a few days, but for now here are
> some bullet points.
> 
> 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)
)
> 
> DParam Behaviour API:
> - Behaviours are no longer gobjects - this was too heavyweight.
> - Behaviours can be chained (eg, a multiply behaviour could use the values
> of two sine behaviours to calculate its result
> 
> Currently I have designed (not implemented) the public API and will
> hopefully continue to develop it over the next few days.
>
just let me know when you have more. if its done I will help to port the threee
plugins over that are currently use dparams.

> The old dparams library will stay where it is and the new one will
> eventually appear in gst-plugins/gst-libs. It won't be committed until the
> 0.9 branch is open. Until then I'll be posting patches to bugzilla for
> people to try out and comment on. Once all elements are moved over the old
> library can be deleted.
> 
> I'm not sure where this leaves your development, probably waiting for me
> to get something working. Could you explain what you need for global/voice
> params so I can make sure my design can implement it?
> 
> cheers
I have posted another file to docs/random/ensonic about interfaces.
A short summary of our goal and requirements. The app we write (buzztard) is a
music composer (something like a tracker). An essential thing we need is
sound-generators that are instruments (therefore the thoughts in
interfaces.txt). 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'.
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.

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/20040722/b62c3308/attachment.vcf>