Re: [linux-audio-dev] XAP: a polemic

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] XAP: a polemic
From: Tim Hockin (thockin_AT_hockin.org)
Date: Wed Dec 18 2002 - 11:18:24 EET


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

Well, I'd been assuming hints were strings, and controls could have multiple
hints. With things like TEMPO, etc, it is more than just a hint. It has to
be the right hint, datatype, range, etc. Perhaps macros for declaring the
most commonly hinted controls

#define XAP_DECL_CTRL_TEMPO(name) \
        XAP_float_ctrl name = { \
                ... \
        }; \

> 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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Dec 18 2002 - 11:23:50 EET