14 Dec
2002
14 Dec
'02
10:12 p.m.
On Sunday 15 December 2002 00.32, Paul Davis wrote:
you're ignoring *plugins* that want to work with B|b|t durations.
the canonical examples that i've mentioned several times are
tempo-synced LFO's and delays. these can either be plugins on their
own or more likely for XAP, integrated into a modulation section of
an "instrument".
Exactly.
Unless I'm missing something, all you need for this is a way for
plugins to keep track of the tempo (sync) and musical time (lock).
The TEMPO + POSITION_* event set I proposed should be sufficient for
for sample accurate lock to musical time, even accross tempo changes
and transport skips.
It is not just "very nice"; it's a required feature, IMNSHO.
And it should preferably be sample accurate, and capable of tracking
even the most furious tempo maps. Someone will complain sooner or
later if they aren't.
I would like to clarify something here: musical time as used in an
API is not by definition "periodic". (That's just an interpretation
of it, normally based of the time signature.)
The APIs that don't use audio frames for timestamps and song position
generally use "ticks". 1.0 per quarter note is a fine unit, for
example, if we (like practically everyone else) decide to use the
quarter note as the base. It's rather handy, because a quarter note
is always a quarter note, but a bar might be anything...
The important point is that musical time represents the movement of a
*timeline*. Unlike audio time, it is not free running time in any
way, but a representation of the sequencer's idea of time. That is,
locking to musical time is essentially the same thing as locking to
the sequencer. And if you do that, your plugin and the sequencer will
have a common reference for time, that the sequencer can play around
with as it wishes, while you can just modulate some audio with
(sin(musical_time * M_PI * 2.0) + 1.0) or whatever. ;-)
//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 ---
* Is there a good reason to make event system
timestamps
relate to musical time rather than audio time?
Again, I would rather let the timestamps deal with audio time.
Hosts which work in bars/beats/frames
should be capable of doing the necessary conversion. Remember,
there are plenty of
parameters which might need some time indications
but which are completely unrelated to notions of tempo. I'm
thinking mostly about LFOs and other modualtion sources here
(although there might be good grounds for lumping these in with
frequency controlled parameters.) Just as I would rather
yes, sometimes you might want to control them quite independently
of tempo. but lots of the most interesting instruments in the
software synth world now allow tempo sync as an option, and its
very nice to have it available. see pitch
control make as few assumptions as possible about tuning
and temperament, I would like to see time control make as few
assumptions as possible about tempo and duration. Sequencers
generally do operate within the shared assumptions of traditional
concepts of periodic rhythm, but in a lot of music (from pure
ambient to many non-Western musics to much avant-garde music)
such notions are irrelevant at best.
true, and i've been known to make this point myself. but the fact
that there is a lot of music in which periodic rythmn is irrelevant
doesn't erase all the music in which its a central organizing
principle. coming up with an API that doesn't facilitate periodic
(even if highly variable) structure when arranging things in time
makes working with such music more cumbersome than it need be, some
of the time.