[gmpi] Re: Reqs 3.9. Time - opening arguments.1
- From: "Michael Stauffer" <michael@xxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 10 Feb 2004 13:12:44 -0500
>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.
OK, I see what you mean. I've been using 'realtime' differently,
exclusively to mean 'transport running' or 'performance/play mode'.
Whereas what you suggest is that realtime could also refer to a plug
that's processing while the transport is stopped, but allows user
monitoring and interaction?
Yes, the offline plug-in I've been talking about would truly do offline
processing. The user wouldn't hear or see anything while it's processing,
and twisting knobs, etc, would have no effect during processing.
>> 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?
Yes, that's it. But just to be clear, overall I've been talking about
both kind of tempo functionality - JIT delivery of events while the
transport is running, and publishing a tempo map while the transport is
stopped.
>> >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.
Yes. Currently, a host's static tempo map is master unless the user
designates an external tempo sync source (midi clocks, ReWire), so I've
been imagining that if we let plugs make tempo changes while the
transport is running, the host is going to be in external sync mode
anyway and so its static tempo map would be ignored.
If a plug can set the host's *static* tempo map while transport is off,
then the source of tempo, once transport is started, is still the host
*if* external tempo sync is off. I'm interested in getting the static map
directly into the host, because what I care about most for my current
needs is getting the static tempo map into the host so the host can use
it for other processing (beat slicing, msr/beat alignment, etc.),
generally offline.
>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.
Dynamically altering a static map from different sources gets tricky. If
a plug or other external source alters the tempo, what does the host (or
owner of the master static tempo map) do when the next tempo from the
static list comes due? Is it applied relative to the current tempo or
absolutely?
It probably does not make sense to have more than one realtime tempo
source at a time. Or if so, there might need be a designation of who's
got master control, and all other changes are made relative to the master
tempo controller's idea of what the tempo should be doing. Ie, the master
tempo controller could set absolute tempos or relative tempos, but other
tempo controllers could only offer relative tempo changes. I don't know,
sounds too complicated. Does anyone have any realworld examples of the
utility and feasibility of simultaeneous tempo masters?
For setting of a static tempo map, there could be several sources, and
the user would have to understand the relationship between them if he
were to use several simultaeneously.
>> >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.
Hmmm. For offline analysis, why would softsynths play? Could an offline
plug simply analyze the host's current audio selection without using the
rest of the graph? Although, I guess it might be useful for a different
plug to be between the host and my plug and provide some pre-processing.
Or, if my plug was analyzing the output of the softsynth plug, then the
softsynth plug would need to process things first.
Yes, I see where it gets sticky. I'm not sure how offline-type analysis
is currently done in plugs, ie analyze and replace, or something like
that. Could someone fill me in quickly?
>> 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.
Yes, that is it.
>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.
Yes, a critical question is how offline processing is handled within a
graph. ie Can a plug request to simply grab the host's audio selection
for offline processing, without going through the rest of the graph?
For special purpose plugs like I'm proposing, it might be that the user
simply has to insure (or the plug itself checks) that it is in a graph by
itself, to avoid the possible complications?
>Am I starting to grok your point?
Yes. :) And I'm seeing a better view of the complications from trying to
do this is a general way.
Cheers,
Michael
----------------------------------------------------------------------
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:
