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

  • From: "Michael Stauffer" <michael@xxxxxxxxxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Fri, 20 Feb 2004 19:52:32 -0500

>6. Realtime tempo follower
>  A plugin wants to analyze incoming audio and control the tempo and
>  possibly meter of sequenced tracks.  For example, a live guitarist and
>  percussionist with sequenced synths.   The live musicians can
>put in small
>  tempo fluctuations to give the song a better live feel.  The
>plugin can
>  analyze the live audio and keep the sequenced synths in time.
>       - Plugins must be able to generate tempo and meter
>changes for other
>         plugins.

Just to clarify, the plugin must be able to generate tempo and meter
changes for the host too? ("realtime" events, that is, not "offline").

And I agree with Tim that realtime and offline are different animals.
From the hosts perspective, realtime is like sync'ing to midi clocks, and
offline is like loading in the tempo map from a midi file.

>7. Offline tempo analysis
>  A plugin wants to analyze some audio input and produce a
>fixed "map" of
>  tempo and meter changes.  For example, the user records a live pianist
>  without a click, and wants to add some sequenced string
>parts.  The tempo
>  fluctuates during the performance.  The plugin can detect those
>  fluctuations and produce a static list of tempo and meter
>changes.  The
>  host can use that tempo map to control sequenced tracks, for
>beat mapping,
>  and for time stretching.
>       - Plugins must be able to push a structural tempo map to
>the host.
>       - This use case seems to be out of scope of GMPI.  It is a very
>         specialized case which requires a whole sub-API to handle these
>         tempo maps. Arguments to removing it?

I have only one argument in favor of having this somehow in the API.
There's been a little bit of discussion about allowing tempo/meter
lookahead for plugs. This of course would only be relevant when the
host/tempo-controller were playing from a static tempo map. It doesn't
sound like this capability will be added, and I agree that it probably
isn't worth the extra complications. But *if* this capaiblity is added to
GMPI, I suggest that a corresponding API call be included to push static
tempo map events back to the host/tempo-controller. This could use the
same static tempo map event format that is used for lookahead. This could
be optional for hosts to implement, but would leave the door open for
future use of GMPI along these lines.

Alright, I've said my piece. Thanks for listening! :-)


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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: