[gmpi] Re: Reqs 3.9. Time - opening arguments.1

  • From: "Michael Stauffer" <michael@xxxxxxxxxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Mon, 9 Feb 2004 19:01:17 -0500

>On Fri, Feb 06, 2004 at 08:35:32PM -0500, Michael Stauffer wrote:
>> Regarding GMPI and tempo - like David pointed out earlier, I
>think it's
>> important to distinguish between realtime and offline uses
>and needs of
>> tempo information. To avoid confusion, I'll try to use these terms (or
>> something better if someone suggests):
>And I don't really see the tempos as different, I see the
>application/pluugin as different..read on, and I will try to make myself

Yes, the tempos themselves might not be different in one sense, but the
application/use and manner in which they are applied and handled by the
host are different.

>> "offline tempo map"
>> Tempo information stored about a whole song/sequence, or section of a
>> sequence, like the traditional tempo map concept we're used to in
>> sequencers and midi files. The host itself (assuming it has sequencing
>> capaiblities and isn't just a dedicated GMPI host) will have
>(at least)
>> one offline tempo map for its current project/song/sequence.
>In a realtime environment this does not exist, right?  At any point, the
>user may change the tempo.  And now, if we are to allow
>tempo-changing from
>plugins, a plugin may change the tempo at any point.

Yes, this is NOT for realtime activities. I assume by realtime here we're
talking about when the host and associated plugs are "playing/recording"
or "performing", ie while "conductor time" or "stream time" are currently
running/changing, using two of the proposed terms. By offline, I mean
when the transport and conductor/stream time are stopped. When the host
and plugs are (generally, at least) idle.


>OR look at it more simply:
>Any plugin which changes the tempo falls into one of four classes:
>1. realtime responses to realtime input
>2. needs the full input before generating responses (offline)
>3. needs significant input before generating responses (latency)
>4. not based on input
>If your plugin falls into class #1 or #4, it works equally well
>in realtime
>or offline.  If your plugin falls into #3, it CAN be run "realtime" with
>latency compensation.  If your plugin falls into #2, you need
>extra help.
>Are we talking about handling #2 specially?  If not, I posit
>that there is
>no such thing as an offline tempo map.  Tempo is a function of
>all inputs,
>including other plugins.

Yes, #2 would be an "offline" plug, in that it analyzes a chunk of audio
data passed to it by the host (or other plug, I guess) while the
host/transport/conductor/stream is stopped. I agree that there needn't be
a concept of offline tempo map for within plugs, but if the plug wants to
set the host's idea of tempo changes within a project, you're talking
about tempo maps, and "offline" distinguishes it from realtime tempo
changes. The relationship is that the offline map is used to
determine/control realtime tempo in the absense of any other tempo events
coming in from other sources (during realtime performance).


>> offline tempo maps
>> ==================
>> I'm not sure why it would be prohibitively difficult for a host to
>> implement support for these from a plug. In any(?) host that
>will show me
>> the tempo map, I can make changes to the events in the map, insert new
>> tempos, or I can draw a new tempo map, and the host takes
>care of making
>> sense of the changes with respect to the song/project. These
>actions seem
>> generally to be undo-able.
>So you're talking about dynamically changing the global tempo
>map?  I don't
>see that as any different from a synamic tempo map.

I'm not sure what you mean here? What specifically does "dynamic" mean
here? Yes, I'm talking about changing the global tempo map (if you mean
the host's tempo map, or the tempo map as defined by whatver controller
will end up controlling it). I'm talking about the tempo map that defines
all the tempo changes that will happen while the host is running if no
other tempo changes come from any other source.

>> Plug-ins might have their own offline tempo-maps, but I would suggest
>> that there be a clear hierarchy, along the lines of the
>> "upstream/downstream" selection for tempo control made
>earlier. If a plug
>> wanted its offline tempo map to be dominant for all plugs and possibly
>> multiple plug graphs, it would submit its offline tempo map
>to the host.
>> Then it would get passed to any downstream plugs without their knowing
>> necessarily that it was set by another plug, and they could still
>> optionally ignore it or modify it for streaming or offline needs.
>This is how I have been coming to think of the issue:
>assumption: Tempo changes are delivered JIT to plugins, or the plugin
>queries for them.
>assumption: Any single plugin is driven by a single music-time master.
>There may exist multiple music-time masters, but each plugin
>has ONE ONLY.
>If your plugin wants to be a music-time master (control tempo,
>meter, etc)
>then it must tell the host that fact.  The host is responsible assigning
>music-time masters to plugins (possibly by user input).
>For example, a host might show a dropdown list for each plugin
>that has a
>TEMPO input.  That dropdown says "Music-Time master:" and has
>options for
>"Builtin (default)" (the hosts's tempo controller) and "Foo TimeTracker"
>(some tempo controlling plugin).
>If you select the "Builtin", then your plugin will get it's tempo events
>from the builtin tempo controller.  If you select "Foo
>TimeTracker", then
>your plugin will get it's tempo events from the tempo controller in the
>TimeTracker plugin.

Yes, something along these lines sounds good. Have to think about the
HOST also being able to designate where it's tempo input come froms, ie
maybe from a plug.

>> What I'm envisioning for my own plug-in would be to get audio
>data from a
>> track or track selection in the host, process it for tempo,
>and pass back
>> the tempos (and time-signature), with timestamps that allow
>the host to
>> apply them at the correct point in the song/sequence. One of the
>So your plugin requires the full input track BEFORE it generates it's
>output?  That sounds to me like an ofline plugin that requires special
>assistance.  We've talked about offline plugins that require multiple
>passes.  We have not gone into detail on that yet.  Maybe this
>requires a
>pre-process scanning pass?

Yes, one of the plug-ins I'm planning on is an offline plugin. I remember
reading that offline processing would be supported in the GMPI
requirment, but maybe I don't understand it correctly? If a user
highlights a track or a section of audio in a track and designates a
plug-in to process it, what happens? Doesn't the data get fed to the
plug? Mine wouldn't need multiple passes. How would a pre-process
scanning pass be different than a regular pass? Is the data sent to an
offline plug via consecutive individual chunks/buffers, or as a vector of
some sort to the complete array of data buffers in some way?

>It would be much more interesting to do real time analysis of an input
>stream and adjust the tempo of that, perhaps with small latency.

The interest depends on what you want to do. For changing
realtime/performance tempo while the host is playing, real time analysis
is more interesting. If you want to analyze a performance that's already
been recorded, and then effect things like the tempo and beat map for
slicing, time-stretching, etc., then offline analysis is interesting and
required. They really are two different needs.



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: