15 Dec
2002
15 Dec
'02
11:24 p.m.
On Monday 16 December 2002 03.22, Paul Davis wrote:
Who said anything about samples/second?
just an example unit. you can't get any information about a
continuously flowing time by watching non-monotonic, discontinuous
positional data.
No, you're right, of course. It's just that if the information comes
at regular intervals and with reasonably accurate timing, you can
"guess" the relative speed of time where they come from, by looking
at two or more events. If you don't get at least few hundred messages
per second, what else can you do?
no, i didn't mean anything but that. its just that unless you know
that the positional data is "not normal", its useless as a time
reference. you can certainly lock to it, and move along the
timeline based on your current notion of direction and speed. you
just have to be ready for that to be revised at any time, and for
the current position to change in arbitrary ways at any time.
Yes indeed - that's exactly what I meant, but I seem to be using the
wrong terms all the time... :-/
[...]
of course you can do that. the point is that the SMPTE sync between
the VCR and the sequencer is completely unrelated to the "sync"
used by the audio interface (its own clock source, for example, or
wordclock).
Well, yes. The former is positional, while the latter only affects
the sample rate, or "speed". If it still sounds like I'm taking those
for equivalent, I think I'd better STFU and learn english.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
Positional data
sort of implies that you can extract timing
data as well, provided you get a stream of positional data
with sufficiently accurate timing.
no, you can't. how rapidly we are moving through a series of
events on a timeline has nothing to do with how many samples per
second we expect to process. we could be playing something at half-speed, for
example, or scrubbing using an MTC/MMC/SMPTE power jog wheel.
Sure, that's exactly what I'm thinking about. You're suggesting
that you *must* wait for each positional "event" before you do
anything at all?
What I'm talking about is just what every reasonably well written
sequencer does when you tell it to lock to something. see above. you're confusing two entirely separate
types of
synchronization.
Confusing what with what? You can't sync a sequencer to a VCR, and
let the audio interface (for the softsynths, or whatever) run at a
fixed sample rate? Seems to work really rather well if the "audio
interface" is built into an external MIDI synth, that doesn't sync
or lock to anything it all...