From: Steve B. <st...@st...> - 2004-07-22 21:25:46
|
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 |