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

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Mon, 9 Feb 2004 17:07:25 -0800

On Mon, Feb 09, 2004 at 07:01:17PM -0500, Michael Stauffer wrote:
> >> 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.

The way I have been thinking of realtime vs. offline is this:

Realtime processing will let me listen to the data as it is processed,
with some latency.  The min latency is your soundcard buffer, but plugins
may induce further latency.  The stream may change at any time based on user
actions.

Offline processing is done from start to finish before I get to listen to
it.  There are things that can be done here that can not be done realtime
(or can not be done without significant latency).  User actions do not
occur during processing.

For example, a realtime stream might be subject to my random twisting of GUI
knobs, MIDI controllers, or musting of channels.  Offline processing is not
subject to those.

Another example, you can't normalize a realtime stream, but you can
normalize an offline stream.

> 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).

OK, so I think I got a glimpse of what you are envisioning.  I've been
assuming that a tempo map is a series of events, and that those events which
come from a plugin like your time follower would always be delivered Just In
Time.  Thereby there is no "tempo map" published, just some controller which
sends out events as needed.

What I think you are asking for is a way to pre-process some data, generate
a list of tempo events relative to that data, and then expose that list of
events as a tempo map.  Is that right?


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

The key part is "if no other tempo changes come from any other source".
Provided that the user does not change the tempo and that no other plugin
changes the tempo, you can consider your plugin's map the master.

I was thinking of a static master tempo (in many cases constant) which could
be dynamically altered by events from a plugin.  But there would be no a
priori knowledge of those events by the master, just JIT events.  Not so
good from a UI point of view.

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

Your plugin would not need multiple passes, but the graph as a WHOLE would.

First, do a pre-process pass.  Plugins like yours can scan their audio input
and generate internal events.

Second, do a process pass.  Softsynths and the likes would play, your events
would be delivered and the tempo controlled.

Third, do a post-process pass.  Things like normalizers could scan the
entire data and process it.

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

So what you really want is a way for to bundle a bunch of tempo-change
events together into a tempo map, and to expose that tempo map in it's
entirety.

The part that I have been leaving out is "in it's entirety".  Because other
events may come in from the user or other plugins, I have been seeing this
as not useful.  It's correctness is still dubious, but it does seem useful.

Am I starting to grok your point?

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