> > pos_in_ticks += ticks_per_sample
OK, then you have a position in ticks in a floating point format,
which is correct at each sample across the timeslice. Using floating
point makes that kinda easy. But why is this important, or rather,
what fraction of plug-ins will need to do that? You already have
events stapled to index offsets, and could convert the offsets into a
ticks-plus-stepped-fraction when you need them, and you could
subscribe to events like I describe above if you want sprocket holes.
The advantages of floating point musical time are not so great.
I get what you're saying now. Plug says 'tell me every N ticks', and host
does. It solves edge detection, and eliminates the need for the plugin to
track pos. Storing fractional ticks can be left to the plugin.
I rather like it.
> >I think Mike Berry made a pretty good case for it.
Yeah, that was pretty far-sub. I think we'll need something sub, but
still need to look closer. I.e., is
common-multiple-of-44100-and-48000 the only answer? What if the
system is operating with pull-down or pull-up, so you've got to work
with, like 44050 and 48000? What about the future when we have
sample rates like more 120 kHz? Then the LCMs can get pretty big.
Do we need a fractional value? Etc. etc.
I think the sample_rate * subsample_rate idea is flexible enough to answer
all that for all hosts, and 64 bits should still be enough for a while :)
