18 Dec
2002
18 Dec
'02
5:23 a.m.
On Wednesday 18 December 2002 01.25, Tim Hockin
wrote:
> > > 1) the host->tick_me(plugin, 100, cookie) // call me back in
> > > 100 ticks - This could be a simple host-based time-management
> > > API - This depends on a 1-1 map between host and timeline,
> > > which I think is ok
Doesn't work for *position* changes, though, which
is what I was
really thinking about. If it turns out that you just missed the
event, should it be thrown away, kept indefinitely, adjusted to the
start of the current block, or quantized to the first beat (or
whatever) in the current block, or later blocks, or what?
Or just toss away all tick_me events on a transport jump. Or see my other
email about escrow - one API to say loop these events, and one to say toss
them.
I'm not really arguing for this, just playing it out..
As long as it
does not need to be special cased, I can buy this.
Our notion of 'hints' has gotten pretty strange though.
Hmm... Yes. What *are* they, actually? Do we need type hints as well
as other hints? Multiple hints per control? Some catching up to do...? ;-)
mostly caught up, and it seems we weren't far off the mark to start with.
I'll summarize again here. Please correct me if I am wrong or missed
something:
Time in XAP:
-----
SAMPLE_RATE: all plugins know this from create()
- units: frames/sec (uint)
TEMPO: a plugin can have a TEMPO control
- units: beats/sec (float)
- deliver a TEMPO event at plugin init and whenever the tempo changes
TIMEBASE: fixed value
- units: ticks/beat
- fixed at 1920
METER: a plugin can have a METER control (or controls)
- units: beats/measure (float) and beat-note-size (float)
- another option: encode as a fixed-point value and int inside 32 bits
- deliver a METER event at plugin init and whenever the meter changes
TRANSPORT: a plugin can have a TRANSPORT control
- units: absolute ticks (float)
- deliver a TRANSPORT control when transport starts (start tick), stops
(negative), jumps (new tick value) and periodically (recommend each beat
or each measure)
There is then some mechanism to convert values. This answer is still not
clear yet. Which exact transforms do we need to provide (SDK), and which
data/transforms does the host/timeliner need to provide?
Is meter simpler as QN/beat and beats/measure, with tempo = QN/sec and
timebase=1920 ticks/QN ? It seems that this is how most everyone else does
it. Is it simpler, or is there a reason they do?
Now, correct me if I am wrong about any of this? Let's wrap up the time
discussion and get another draft out soon. Lots more to do :)
Tim