16 Dec
2002
16 Dec
'02
9:39 p.m.
David Olofson wrote:
right on.
seconds_per_tick is what i actually use, and it's central
to easily mapping ticks to seconds, and from there to frames.
seconds-per-beat would be a little exotic actually, sorry
for bringing it into play.
in a system where audio is the master clock, the time i mean
is simply frames / sample_rate.
i don't care how complicated you make it, it just has to be
there. ;)
besides it's ok by me to complicate life for host coders.
it's the plugins that should get the better part of the deal.
tim
you absolutely
need ppq for the tick system to properly map
different measures (5/4 time, 6/8 time etc) as per previous
post.
I'm not sure if you absolutely need it (you *can* translate), but
indeed, it's *much* nicer when the "speed" of musical time depends
only on tempo, and not the whole meter. add
seconds-per-beat for plugins that are not limited to
audio purposes.
How about checking the audio sample rate? (Yes, that will not map
exactly to seconds, but it *would* allow you to have the same idea of
"1 second" as your wordclock sync'ed audio devices, which seems much
more useful to me.)
If you want to deal with *actual* wall clock time to do some I/O,
you're in the wrong thread (host audio thread) and/or asking the
wrong questions, I think. Anyone here ever used non-integer # of beats/bar,
and/or "weird" note
lengths?
non-integer is not proven to be needed i think. if you say you
need 9.5 beats per measure, simple make that 19 half beats. it
is a lot simpler to implement on a machine, and the denominator
is just a matter of convention but not of precision.
* time in
seconds
What time? Wall clock? If you have the current time info struct,
it'll contain that (as calculated by the timeline "driver", based on
audio latency), and then you can convert back and fort as you like
by, though musical time position/"tick". a separate
function. i have opted for the latter -- to keep
things sane, b.b.f conversion is only done for ticks and
vice versa though.
Yeah, it's just that that would be a *lot* of calls if you want to
cover all combinations. Look at VST's VstTimeInfo, or whatever Paul's
corresponding struct in JACK is called; those cover what you need.