14 Dec
2002
14 Dec
'02
10:24 p.m.
David Olofson wrote:
It is not just "very nice"; it's a required feature, IMNSHO.
Right.
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.
Ok, fair enough. Yes, the approach you outline above seems reasonable.
* 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.
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.
Absolutely.
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.
>
Point taken.
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...
Well, not necessarily! A quarter note is not always the unit of a
single beat. In traditional
music theory, 6/8 meter is frequently thought of in 2 - the
dotted-quarter note gets the beat.
Half-note based meters (2/2, 3/2) are also very common, and things like
5/16 are not
uncommon in modern music. That said, I think what you mean by
quarter-note is
what I would call "counting unit" or "durational unit" or something
like
that.
while you can just modulate some audio with
(sin(musical_time * M_PI * 2.0) + 1.0) or whatever. ;-)
Nice. Sounds like fun.
//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 ---