From Buzztard

GObject Params already carry some metadata with them. Sometimes this is not enough.

[edit] Adding special data to existing param-specs

Luckily there is g_param_spec_get_qdata(),g_param_spec_set_qdata(). With this we can add custom data. The question is, where do we put the GQuark definitions in. To make the extra data useable among different apps, we need to register it. A logical place seems to be a gstreamer module that has all ifaces and other definitions plugins need.

[edit] Extra data provided by buzz

• a no-value:
• a flags value:
  • MPF_WAVE: parameter value references a wavetable slot
  • MPF_STATE: parameter is continuously changing (not used for notes and triggers)

[edit] Trigger params

[edit] Keyboard notes as gobject-params

[edit] GParamSpec type

Although a note such as 'C-3' can be represented numerically, it would be better to have a type for it.

So we need to register our own paramspec-type. A remaining question is if we should use an own value-type too?

GType gst_param_spec_musical_note_type;

static void
param_musical_note_init (GParamSpec *pspec);

static void
param_musical_note_set_default (GParamSpec *pspec,
			GValue     *value);

static gboolean
param_musical_note_validate (GParamSpec *pspec,
			GValue     *value);

static gint
param_musical_note_values_cmp (GParamSpec   *pspec,
			const GValue *value1,
			const GValue *value2);

static const GParamSpecTypeInfo pspec_info = {
  sizeof (GstParamSpecMusicalNote),    /* instance_size */
  16,                                  /* n_preallocs */
  param_musical_note_init,             /* instance_init */
  G_TYPE_UINT,                         /* value_type */     /* or use own value-type ? */
  NULL,                                /* finalize */
  param_musical_note_set_default,      /* value_set_default */
  param_musical_note_validate,         /* value_validate */
  param_musical_note_values_cmp,       /* values_cmp */
};
gst_param_spec_musical_note_type = g_param_type_register_static ("GParamMusicNote", &pspec_info);

Check the param_string_ functions for the implementation of the callbacks. In the header file we need

#define GST_TYPE_PARAM_MUSICAL_NOTE	       (gst_param_spec_musical_note_typ)
#define GST_IS_PARAM_SPEC_MUSICAL_NOTE(pspec) (G_TYPE_CHECK_INSTANCE_TYPE ((pspec), GST_TYPE_PARAM_MUSICAL_NOTE
#define GST_PARAM_SPEC_MUSICAL_NOTE(pspec)    (G_TYPE_CHECK_INSTANCE_CAST ((pspec), GST_TYPE_PARAM_MUSICAL_NOTE, GstParamSpecMusicalNote))

typedef struct _GstParamSpecMusicalNote       GstParamSpecMusicalNote;

struct _GstParamSpecMusicalNote {
  GParamSpec    parent_instance;
  
  /* what fields do we need ? min/max ?*/
  gchar default_value[4];
};

GParamSpec*	g_param_spec_musical_note(const gchar	 *name,
					  const gchar	 *nick,
					  const gchar	 *blurb,
					  gchar		 *default_value,
					  GParamFlags	  flags);

For a full example, see glib/gobject/gparamspec.c, glib/gobject/gparamspec.h, glib/gobject/gvaluetypes.c, glib/gobject/gvaluetypes.h and glib/gobject/gtype.c.

[edit] Note to Frequency translation

The implementation can have several tuning tables to translate from a note to frequency. See [1] and [2] about tuning.

enum GstNote2FrequencyTuning {
  GST_NOTE_2_FREQUENCY_CROMATIC=0,
  ...
}

class GstNote2Frequency {
  GstNote2Frequency *gst_note_2_frequency_new(GstNote2FrequencyTuning tuning);
  double gst_note_2_frequency_translate(GstNote2Frequency *self,gchar *note);
}

The constructor would lazilly create the tuning tables on first request.

[edit] Dynamic Parameter ranges

GObject properties have class wide limmits. This limmits usefulness. E.g. the cut-off parameter of a filter has only meaning from 0 Hz to sampling-rate/2 Hz. But this changes per instance and at run-time.

[edit] Adding special functions

We need to make his a interace. This can hold the quarks and provide the functions.

[edit] Extra functions provided by buzz

Buzz has a functions that converts the numerical state of a property into human readable form.

[edit] Implementation

• Where to put it (gstreamer,gst-buzztard)? For now an iface in gst-buzztard would be okay.
• How name it? gst_parameter_meta, gst_property_meta