[gmpi] 3.9 (draft) use cases and stuff
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: GMPI list <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 18 Feb 2004 12:12:16 -0800
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
