gstreamer/docs/random/ensonic/interfaces.txt

$Id$

* existing gstreamer interfaces
  ./gstreamer/gst/gsttaginterface.c
  ./gstreamer/gst/gstinterface.c
  ./gstreamer/gst/gsturi.c
  ./gst-plugins/gst-libs/gst/propertyprobe/propertyprobe.c
  ./gst-plugins/gst-libs/gst/mixer/mixer.c
  ./gst-plugins/gst-libs/gst/tuner/tuner.c
  ./gst-plugins/gst-libs/gst/xoverlay/xoverlay.c
  ./gst-plugins/gst-libs/gst/colorbalance/colorbalance.c
  ./gst-plugins/gst-libs/gst/navigation/navigation.c
* new general interfaces
  * GST_TYPE_PRESET_MANAGER
    - add preset managment
    - API:
      GList *get_presets();
      void activate_preset_by_index(glong index);
      void activate_preset_by_name(const gchar *name);
      void add_current(const gchar *name);
      void remove_preset_by_index(glong index);
      void remove_preset_by_name(const gchar *name);
    - features
      - there should always be a default preset
    - questions
      - were and how do we store the presets?

  * GST_TYPE_UI_HINT
    - add hints to generate 'good' looking interfaces to elements
    - API:
      GList *get_group_list();
      struct ui_hint_group {
        gchar *label;
        gachr *role;
        GList *entries;
      }
      struct ui_hint_group_entry {
        enum UiHintGroupEntryType type={PARAM,DPARAM};
        gchar *name;
      }
      roles {
        /* graphics */
        "color_selection/rgb",
        "color_selection/hsv",
        "aspect_ratio",
        /* audio */
        "envelope/adsr",
      }
    - features
      - grouping of parameters, each group has:
        - a label: giving a title to the group
        - a role:
          - this can give the UI a hint about the purpose of the controls
          - this only makes sense, if we dont make this a thousand templates
        - a list of dparams or properties
    - question
      - should this be aware of instruments (voice-groups)
        - no, instruments should auto-generate those
  * GST_TYPE_QUALITY_VS_SPEED
    - get the name of a property that can be used to switch between
      - a fast version for e.g. realtime usage
      - a slower version with higher precission that can be used for off-line
        rendering
* new interfaces for audio applications
  * GST_TYPE_MULTI_VOICE
    - control interface for elements that support multiple voices (in one output-pad)
    - API:
      gulong number_of_voices;
      void add_voice();
      void remove_last_voice();
      gulong get_number_of_voices();
    - features
      - plugin will initially have one voice and that one can not be deleted
  * GST_TYPE_MUSIC_GENERATOR
    - add hints so that application can use a element as an instrument
    - API:
      // param types
      DParam *get_note_dparam();
      GList *get_trigger_dparams();
      // -- or
      DParamType get_dparam_type(DParam *);
      dparamtype = { NOTE, TRIGGER, OTHER }
      // voices
      char *get_number_of_voices_property();
      GList *get_global_param_names();
      GList *get_voice_param_names();
    - features
      - find out which params to use to play notes/trigger sounds
        - these params will not appear in a control-ui
        - notes involve a key to frequency translation
      - find out if the element has a number_of_voices property
        - if yes, we can find out about the max by looking at the gparamspec
        - setting the property, adds/removes voices
        - if the element supports it, it needs to:
          - register voice-dparams as e.g. note_XXX, where XXX is the voice-number
          - run the voice-loop in the chain/loop function
            each voice processes the same input, if at all
            the outputs of all voices are mixed together