15 Dec
2002
15 Dec
'02
6:20 p.m.
David Olofson wrote:
block/cycle boundaries exist because hosts do block/cycle
based processing -- and will do so for a couple of years
on commodity hardware. conceptually, blockless processing
is no different from one-sample sized blocks.
if you change/add tempo map entries while only half your
network has completed a cycle, you're in deep sh*t. i
found the easiest solution to be preventing this from
happening in the first place.
i don't see how this plays into sample-accuracy matters.
if you think in any form of transport time, be it ticks,
seconds or frames. this is the time context that plugins
operate in. any other concept of time is orthogonal.
that's what a system-wide uniform time base requires.
tim
> >Musical time *stops* when you stop the
sequencer, which means that
How would you go about implementing an event delay
effect?
by definition, time isn't flowing when the transport is
stopped. a delay in stationary time can only be a zero
delay because there's no future. this doesn't preclude
other ways of processing, ie. plugins might only refrain
from scheduling future events in stopped state.
This won't help if you're locking to an
external device. (I'm sure
Paul can explain this a lot better - I only seem to confuse people
most of the time...)
yes, because you are confusing things yourself. there is
only one time within one system. if you sync this system
to external, the flow of this time sways somewhat, but
it's still one integral time.
you may also
want to synchronize changes to the tempo map and
the loop points to be executed at cycle boundaries, which is
how i am making these less invasive, but that's another story.
I certainly wouldn't want the API to depend on such limitations.
Applications may do what they like, but thinking of block/cycle
boundaries as anything more than the limits for the non-zero length
time span that is "now", is not helpful in any way, if you want fully
sample accurate timing. I'm arguing for audio timestamps, because I do not
want plugins to
have two different time domains forced upon them, especially not when
stopping one of them prevents plugins from communicating properly.
it does not, because any point in time can be expressed in
any domain. and to repeat, in stopped state all clocks are
frozen, no matter what they count. and to repeat again,
device-dependent units for information interchange across
implementation/abstraction layers are stoneage methodology.
You're not required to sequencer every event in the
network.
you wouldn't mind either, would you?
transport
control is no event because it invariably involves
a discontinuity in time, thus it transcends the very idea of
an event in time.
Yes - if you think of time in terms of musical time only. and plugins
don't have an internal 'song position counter'.
It could be anywhere, but then you'd have to make a call somewhere
every time you want a sample accurate version of it.