[gmpi] 3.9 (draft) use cases and stuff

I've been trying to distill everything related to timelines into use cases
and then figure out the reqs and problems from there.  Here is a draft of
what I have.

You'll see a bunch of use cases, each of which is followed by the
requirements that use case imposes.  Some of the use cases may not be clear
enough, some may be deemed out of scope, and some may be too detailed.  I'm
looking for input on all that.

TO DO:
-------
- clarify use cases
- add any new use cases
- dump/fix bad use cases
- clarify/add/remove reqs that come from each use case
- explore use cases with big problems (a couple)

This does not fully capture all the reqs that we have been discussing, but
it is getting close.  From this we can really see what timeline info GMPI
needs to track.  Use cases can be very simple, if they demonstrate a
requirement that is not captured here.  If you have a use case that shows a
req that is not in here, PLEASE tell us.

Hopefully this will get some more discussion going.

Tim



1. Timestamped events

  A plugin is called to process a block of 512 samples.  It is given the
  sample time of the first sample for that block.  It might also receive
  some events, stamped with the exact sample time at which time they should
  be processed.

        - Requires sample-based timing for events.

2. Tempo sync

  A plugin wants to do a tempo-synced delay.  The plugin needs to find out
  when the time will be exactly 3 beats from "now" at the current tempo, and
  when that tempo changes.

        - Plugins must be able to find out about tempo changes.  With the
          tempo and sample rate, the plugin can convert tempo delays or
          real-time delays to sample counts.

3. Quantizing

  A plugin wants to quantize musical input to strict musical timing.  The
  plugin needs to find out the current position within the current bar and
  beat, as well as the start of the next bar and/or beat.  The plugin also
  needs to know something about the current time signature to make sense of
  beats and bars.

        - Plugins must be able to find out the position of a sample frame
          within the bar and beat.
        - Plugins must be able to find the edges of bars and beats.
        - Plugins must be able to find out about tempo and meter changes.

4. Step sequencer

  A plugin wants to act as a step sequencer for some other plugins.  The
  plugin needs to trigger events at exact musical times (such as beats and
  bars).  It needs to know the state of playback (paused, playing, stopped)
  and when that state changes.  It also needs to know when the transport
  changes, such as when the user jumps to a different playback position.
  Changes to any other variables that control playback (such as shuttle
  speed) might need to be communicated to the plugin.

        - Plugins must be able to find the edges of bars and beats.
        - Plugins must be able to find out about tempo and meter changes.
        - Plugins must be able to find out about transport position changes.
        - Plugins must be able to find out about playback state and related
          changes.

5. Automatic accompaniment

  A plugin wants to act as an automatic drummer.  It needs to know the tempo
  and the time signature and when they change. It needs to know exactly when
  bars and beats start, so it can lay down accurate drumming.

        - Plugins must be able to find the edges of bars and beats.
        - Plugins must be able to find out about tempo and meter changes.

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.

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?

8. Sequencer tracks

  A plugin wants to act as a sequencer track. The plugin needs to know when
  the playback position changes, so that it's playback head can be adjusted.
  It needs to know tempo and meter, and when they change.  Changes to any
  other variables that control playback (such as shuttle speed) might need
  to be communicated to the plugin.

        Is it notified of transport position in samples?  It would need to
        keep a mapping of all the tempo changes to sample positions in order
        to find the right position.  It's probably easier to notify it in
        musical units - ticks or beats or similar.

        What if meter changes dynamically, but the sequenced data no longer
        makes sense?  For example, if you sequenced at 4/4 but the meter
        changes to 3/4 -- what happens to data sequenced on the 4th beat in
        each measure?  Drop it?  Change it to the 1 of the next measure?

9. Audio tracks

  A plugin wants to act as an audio track. The plugin needs to know when
  the playback position changes, so that it's playback head can be adjusted.
  It needs to know tempo and meter, and when they change.  Changes to any
  other variables that control playback (such as shuttle speed) might need
  to be communicated to the plugin.

        Is it notified of transport position in musical units?  It needs to
        know the history of tempo changes to find the right position.  It's
        probably easier to notify it in samples.

10. Audio to video sync

  FIXME: need a good use case

11. Time conversion

  FIXME: need a good use case

----------------------------------------------------------------------
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: