[gmpi] Re: Reqs 3.9. Time - opening arguments.1
- From: "Michael Stauffer" <michael@xxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Mon, 9 Feb 2004 17:20:20 -0500
>> Latency. Before a plugin processes a block, all it's events must be
>> qued up,
>> that includes tempo changes.
>>
>> Plugins are processed in order 'upstream' to 'downstream'.
>>
>> [A]->[B]->[C]
>>
>> If plug B changes the tempo, there are two ways the host can handle
>> it :
>>
>> - Host can change the tempo map immediatly, in which case C receives
>> the
>> new tempo, but A will have already used the old tempo.
>>
>> or
>>
>> - Host can propogate the tempo during the next 'block', all plugins
>> receive
>> consistant tempo info.
>>
>> Neither case is ideal. Either A and C see different tempo changes
>> during
>> the same song, or all tempo changes are lagged by the graph latency.
>>
>> A clever plugin, aware of the graph latency, could probly
>sync the host
>> successfully to incoming audio, but it's not straightforward.
>
>Jeff, you are right on track!
>
>Your later approach is what i first proposed a while ago:
>//www.freelists.org/archives/gmpi/03-2003/msg00244.html
David, how did it end up working in VST?
I think I understand the issue of latency here, but I'm wondering if it
would effect things any differently than it does in current software and
sync'ing situations. I've only worked with Midi thus far, I'm new to
audio, so what's the definition of a timeslice being used here? Buffer
size / sample rate? I assume we're talking basically about input
latencies due to buffer size + plug-in processing latencies? And with
small buffer sizes and modern OS's, these latencies can get down to mins
of ~2msec? Ie input latency, before processing and output latencies?
I'm wondering ifthese kind of latencies are already an issue in host
tempo processing? Currently, if a host is slaved to midi clocks, the
tempo changes might be received via clocks with ~1msec latencies, but the
effect on any plug-ins will still be subject to the audio timeslice
latency. Ie the plug-in chain won't get the new tempo until it's done
processing the current timeslice anyway. Although maybe the host might do
it's own updating/processing in response to incoming tempo changes while
the plug chain is doing its thing?
With sample-accurate timestamped tempo events, the host could accurately
process the tempo change message from a plug-in for the next timeslice,
whether it arrives during or after the timeslice. Maybe if the host were
to receive the tempo change immediately from a plug-in, it could start
processing it while the rest of the plug-in chain did its thing. Does it
make sense to make tempo events from a plug-in "special" somehow? To
allow only one to be tempo master? Or is that too complicated? Or am I
missing something else altogether?
A further issue in realtime tempo control involves setting of the beat
phase. I'm not an expert on this, I'd have to check for details from the
inventor of our tempo-tracking algorithm if we need to get into this.
Basically, as I understand it, when shifting tempo in repsonse to a
realtime input, it's important to also constantly be updating the phase
of the beat. Midi clocks make this "easy" because the arrival time of the
clock not only sets tempo but implicitly has phase info too, since
there's always 24 per beat, evenly spaced. If the tempo events we're
talking about sending from plug to host(or other plugs) only have tempo
information, then you need two events to set both phase and tempo, since
the first one has to do some fancy footwork to correct for phase, and the
second one sets that actual new tempo. I'm thinking it might be good to
use something like a modified midi clock event, but perhaps more
flexible, in which the tempo master would send events that say "at sample
time S, the exact music is M, and the tempo is T". This allows the host
(or transport controller) to know tempo and phase. This might be an issue
for implementation phase rather than the requirements phase?
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: