[gmpi] Re: 3.9 (draft) use cases and stuff

OK, these are some notes I have been gathering.  These are not ALL the time
requirements, but the ones related to tempo and meter control:


* It is REQUIRED that GMPI support notifying plugins of tempo changes.
* It is REQUIRED that GMPI support notifying plugins of meter changes.

        [[ I think these two are well established by now ]]

* It is REQUIRED that GMPI allow a plugin to control the tempo of other
  plugins.
    - Do they change the tempo of the host?  Or does GMPI need to allow
      tempo controller plugins?  Does the host have to allow this, or is it
      an optional feature (as in VST)?

        [[ I think we all agree on the primary tenet.  We don't yet have a
           conceptual model that is concise.  Maybe that is OK. ]]

* Is it REQUIRED that GMPI allow a plugin to control the meter of other
  plugins (as opposed to just being a host-managed thing)?


I've posted most of this info before, but I want to cut and paste it into
one concise message.  I'd like to put forth a couple models, of varying
complexity/flexibility.  Then we can decide how much complexity we want to
take for the flexibility.  None of these models need be the final answer,
just ways of exploring the issues.

MODEL 1: Traditional-ish
--------------------------

  GMPI just handles instruments and effects and similar.  Sequencing,
  automation, tempo, transport, locate, etc are all part of the host (or are
  at least out-of-band for GMPI).

  The host exposes a tempo map and a meter map, which plugins can peak at.
  Maybe plugins can optionally receive just-in-time events, or maybe JIT
  events are the only method.

  Plugins can change tempo and meter by asking the host.

  Plugins can get information about the musical time of a given sample frame
  by asking the host.

  The host sends events about the transport state and playback location to
  plugins which care about those things.

        [[ What things are missing from this model that people feel are
           requirements? ]]

MODEL 2: Modular
-----------------------

  GMPI is totally modular.  A graph can have an arbitrary number of
  sequencer plugins, tempo-controller plugins, meter-controller plugins,
  transport-controller plugins, etc.

  The tempo-controller plugin sends tempo-change events to the sequencers
  and other plugins that care about tempo.  The meter-controller sends
  meter-change events to the plugins which care about meter.

  A plugin can register itself as a tempo- or meter-controller.  It can then
  send tempo- or meter-change events to the plugins it is controlling (such
  as sequencers).

  Plugins can get information about the musical time of a given sample frame
  by asking whichever plugin is assigned as the timeline controller for that
  plugin (possibly via host-based indirection).

  The transport- and location-controllers send transport- and
  location-change events to the plugins which care about those things.

        [[ What things are missing from this model that people feel are
           requirements? ]]

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: