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

  • From: "Michael Stauffer" <michael@xxxxxxxxxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Fri, 6 Feb 2004 20:35:32 -0500

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

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

"stream tempo" & "stream tempo map"
For the tempo changes/events during a performance, ie while the transport
and/or stream time is running. What form this would take hasn't been
decided (and maybe needn't be for the requirement stage?). This might be
in the form of a list of tempos passed via vector to the plugins, either
all at once, or in pieces at the begin of each block of samples as
suggested previously. It might be individual tempo-related events delived
JIT, ala midi clocks. Or it might be direct callbacks to the host for
direct processing as was also suggested previously. Other forms?

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.

A plug could "simply" pass requests for similar kind of actions; passing,
e.g. a vector of tempos with timestamps relative to the hosts
song/project. These changes could be put on the host's undo stack if the
host desires. If the host has multiple offline tempo maps, the plug would
find out via query and designate for which one it was passing data. Am I
missing something about the complexity of this?

If the plug needed to make sure for some reason that its offline tempo
map changes were accepted and are still in place, it could query the host
for its current offline tempo map and compare it to its own.

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.

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
important features for us would be for a host to then take the tempo map
and make a beat map for time-stretching, slicing and other beat-dependent
processing. For this the host would also need to know at least one beat
position, so the timestamping of the offline tempo events from the plug
might include msr/beat/tick info too. Or, another plug-to-host offline
event would be designation of music time milestones, ie bar/beat onsets,
etc., by sample time.

stream tempo
=============
I agree with Koen if these changes came from a plug, they could be
recorded by the host as automation-type events if desired. I imagine this
stream tempo being alot like current realtime sync via midi clocks or
ReWire. Since most hosts can handle that kind of sync these days, I'm not
sure why it would be too difficult to add support for it from a plug.
Could someone elaborate? Some current hosts record a new tempo map while
sync'ed to external clocks (slaved), and some others don't, while on
others it's a user option.

I see a complication though if multiple plug-ins want to be sync master
to the host.  There would have to some explicit selection of multiple
possible masters, or implicit rules for who's in charge. I imagine a plug
would notify the host that it wants to be sync master and the host would
manage things one way or another if there were multiple choices, perhaps
via a ReWire-style registration method.

Cheers,
Michael

>On Friday, February 06, 2004 12:56 AM [GMT+1=CET],
>RonKuper@xxxxxxxxxxxx <xxxRonKuper@xxxxxxxxxxxxxxx> wrote:
>
>> And, as David said: it can already be done with VST.
>> <<<
>>
>> A VST plugin can send tempo change events to the host, and the host
>> will follow without editing or undo implications?
>
>Well, no VST hosts currently support plugins sending time info
>back to the
>host (well, not that I know of...) But a lot of hosts won't even allow
>plugins to send midi back to the host for re-routing to other plugins or
>tracks either...
>The only exception (regarding time info) is Bidule, where I was said by
>David that it will accept and acknowledge VstTimeInfo from a
>plugin. Don't
>know about editing or undo implications though... Sorry.
>
>But since there had been some talking about use cases:
>Say you have a host that allows plugins to send back tempo info
>to the host,
>which will adjust a "timeline" (as it was called), and several
>plugins are
>taking their time info from that timeline.
>Let's take the example of a plugin that analyzes an audio
>stream and sends
>out tempo changes, and a delay plugin that is synchronized to a musical
>timeline.
>Now, if a tempo change is detected by a plugin analyzing
>streaming audio,
>the new tempo will be sent to the host which will adjust the timeline
>(question: can it go directly to plugins too? I'd guess not), and the
>depending plugins will change their delay times (probably expressed in
>samples internally) accordingly.
>Your question is (if I understood correctly): will the tempo
>change sent out
>by the analyzing plugin and accepted by "the one who controls
>the timeline"
>(probably the host, but maybe a plugin?) be undoable?
>Well, I'm not an expert at all, but I'd guess it should not be undoable,
>unless you record the tempo change events onto a tempo or
>automation track
>(whatever). This feels the same to me as when playing a virtual
>instrument
>while the song is playing on the one hand, and recording the played MIDI
>events on a track on the other hand. What the host stores should be
>undoable, what just happens while playing not. If in Cubase or
>Sonar I move
>a slider in a mixer or in a plugin (without recording that
>movement), it can
>not be undone either. Just my feelings about this. Maybe more
>experienced
>people have better ideas?
>
>> Of course, I'm not a host writer, but I can understand your concerns
>> as it might add complexity over many of the existing systems of today.
>> <<<
>>
>> Tremendous complexity, unless the host was designed from the
>> beginning to support this sort of thing.  I think the popular
>> commercial sequences have one thing in common: they've been around a
>> while, before plugins existed on the host.  So I'm pretty sure this
>> will be similarly challenging for nearly any host.
>
>Challenging? Probably, yes. But why not?
>I know some live musicians that always complain that they can not play
>together with a sequencer, because they can't vary their timing "as they
>feel it". They're slaves to the machine. They just want the machine to
>follow *their* timing and tempo fluctuations. And this IS
>becoming possible
>nowadays.
>
>Anyway, maybe this is something most people here don't want to
>deal with for
>now. But I'd rather try to get the possibility to do this in there now
>instead of waiting another two years for a revision/extension
>of GMPI. How
>do other list subscribers feel about this?
>
>Koen
>
>
>
>----------------------------------------------------------------------
>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
>


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