Subject: Re: [linux-audio-dev] XAP: a polemic
From: Tim Hockin (thockin_AT_hockin.org)
Date: Sun Dec 15 2002 - 07:23:37 EET
> No matter how you turn this stuff about, some things get a bit hairy.
> The most important thing to keep in mind though, is that some designs
> make some things virtually *impossible*.
I think this is the important point - whether the simple timestamp is
sample-time or musical time, SOME plugins need to convert. Now the question
is - which plugin classes require which, and which is the majority. Or
perhaps, if it is lightweight enough, we SHOULD pas sboth sample-time and
tick-time for events?
> I disagree. It's also a technical decision. Many synths and effects
> will sync with the tempo, and/or lock to the timeline. If you can
> have only one timeline, you'll have trouble controlling these plugins
> properly, since they tread the timeline pretty much like a "rhythm"
> that's hardcoded into the timeline.
I don't see what the trouble is...
> Well, if you have two tempo maps, how would you apply the "meter
> map"? I guess the meter map would just be a shared object, and that
> meter changes are related to musical time of the respective map, but
> there *are* (at least theoretically) other ways.
> > being politically quite incorrect, i am happy supporting only
> > one tempo and one time at the same point. imagine how
> > complicated things get when you answer 'yes' two times above,
> > and add to this that i can describe the music i want to make
> > without (even standard polyrhythmic patterns because they
> > usually meet periodically).
>
> It doesn't seem too complicated if you think of it as separate
> sequencers, each with a timeline of it's own... They're just sending
> events to various units anyway, so what's the difference if they send
> events describing different tempo maps as well?
We've been talking about 'TEMPO' and 'TRANSPORT' and 'TICKS' and 'METER'
controls, which (honestly) kind of turns my stomach. This is not what
controls are meant to be doing. the answer strikes me in shadowy details:
Each host struct has a timeline member. Plugins register with the host for
notification of ceratin things:
host->register_time_event(plugin, event, function);
events:
TIME_TICKS // call me on every tick edge
TIME_TRANSPORT // call me when a transport happens
TIME_METER // call me when the meter changes
What about multiple timelines, you ask? Use different host structs. Or
something. If we standardize a timeline interface, we don't have to
overload the control-event mechanism (which forces hosts to understand the
hints or the plugin won't work AT ALL).
Tim
This archive was generated by hypermail 2b28 : Sun Dec 15 2002 - 07:27:34 EET