On Wednesday 18 December 2002 00.53, Tim Hockin wrote:
> > You'll need all these fields at once when sending control ramp
> > events to voices, so unions won't help. The struct is exactly 32
> > bytes, so we're going to end up with 64 byte events if we add
> > anything. On big deal, maybe. (64 bit platforms will need an
> > extra 4 bytes for 'next' anyway.)
>
> I think it is premature to worry about the size of events. Let's
> get what data we need in there and optimize it after we're done
> arguing :)
Yeah, it's no big deal, really. I'm just trying to streamline the
interfaces for other reasons as well - and keeping the argument count
to a minimum coincides with that.
> > Well, you do expect a beat synced effect to track the *beat*,
> > right? Now, if you have two timelines running at different tempi,
> > which one do you track?
>
> Actually, no. I can't think of anything that would track the beat
> if it wasn't started on a beat.
So, how do you suggest a plugin should know when to start...? In all
sequencers I've seen so far, it's perfectly possible to start
playback at any point on the timeline - which may well be in the
middle of a beat. *That's* what locking deals with. (As well as
making sure that you don't drift out of sync due to rounding errors
or other issues.)
> Assuming 4/4 time, and a note
> played on an eith note between beats - what kind of effect would
> lock onto a true beat edge?
A beat sync'ed arpeggiator. (Or it wouldn't be beat sync'ed! Just
tempo sync'ed.)
However, many beat sync effects may not receive any note events or
similar events at all, so they definitely need their "trig"
information from elsewhere - and that is the timeline.
> I really would expect anything to sync
> to a beat-width and do a (delay, whatever), but that effect to be
> off by 1/2 beat because it was started by 1/2 beat off.
That applies only to a few special kind of effects, which basically
all belong in the "tempo sync'ed delay" category. Beat sync is not
the same thing as tempo sync.
> Can you
> give me an example?
Yep, did so. Can probably give you some more, if you like.
> > They need different event types, but that applies to string and
> > raw data controls as well. And this just makes them easier to
> > handle.
>
> I want to limit the number of special case events. If we have to
> special case this stuff, then I'm going to argue against controls
> again :)
Well, then we'll have to implement 64 bit double controls - including
ramping. And the tempo control could end up receiving non-linear
ramps... I'm not sure this is a good idea.
Also note that many plugins that deal with musical time will *still*
have to special-case the tempo and position controls - which means
you get an extra check for every control you receive, just to see if
it's timeline related stuff.
Finally, the meter is two floats (tempo has it's own event), and
nothing like a normal Control event. We could use two float controls
with ramping disabled, though.
TRANSPORT_START/STOP don't need events of their own either. Those
would be a single control where any non-zero value means "rolling!"
(No interpolation.)
Hmm... Ok, so the only special cases I have so far are:
XAP_A_POSITION, /* Set new song position */
XAP_A_TIME_INFO, /* Time Info changed! */
The first is 64 bit double, while the other is just a notification
event that you get in case of an unexpected modification in the
current time info. (Or something. I have to think some more about the
details here. Would like to avoid having plugins polling hysterically
all the time...)
> > Do you expect a synth to play anything but some default
> > frequency, without pitch input? :-)
>
> Umm, more or less, yes. A simple sample player with no pitch
> control would just play the sample. A whitenoise generator would
> make noise but not have any sense of pitch.
Well, yes - they would just use the default values. Same applies to
beat and tempo sync plugins. Just have default values for tempo and
transport on/off, and start with POSITION at 0, and the plugin will
effectively have it's own, free running timeline.
//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 ---
