[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Mon Dec 16 21:25:01 UTC 2002


On Tuesday 17 December 2002 02.33, Tim Goetze wrote:
[...]
> >Anyone here ever used non-integer # of beats/bar, and/or "weird"
> > note lengths?
>
> non-integer is not proven to be needed i think. if you say you
> need 9.5 beats per measure, simple make that 19 half beats. it
> is a lot simpler to implement on a machine, and the denominator
> is just a matter of convention but not of precision.

I must agree with Paul here; non-integer *is* the only correct way to 
express many interesting meters. You can't just "pretend" that a bar 
is twice as long as it really is - some plugins might take your word 
for it!


> >>  * time in seconds
> >
> >What time? Wall clock? If you have the current time info struct,
> >it'll contain that (as calculated by the timeline "driver", based
> > on audio latency), and then you can convert back and fort as you
> > like by, though musical time position/"tick".
>
> in a system where audio is the master clock, the time i mean
> is simply frames / sample_rate.

Ok; then I understand your reasoning.


> >> a separate function. i have opted for the latter -- to keep
> >> things sane, b.b.f conversion is only done for ticks and
> >> vice versa though.
> >
> >Yeah, it's just that that would be a *lot* of calls if you want to
> >cover all combinations. Look at VST's VstTimeInfo, or whatever
> > Paul's corresponding struct in JACK is called; those cover what
> > you need.
>
> i don't care how complicated you make it, it just has to be
> there. ;)

Yes - and there will be ways of converting in all directions; don't 
worry. We're just trying to avoid having a full page of mostly 
trivial conversion functions in the API. For lazy coders, the plugin 
SDK is the place to put inlines and macros for this sort of stuff. No 
need to stuff the API with non-essential features.


> besides it's ok by me to complicate life for host coders.
> it's the plugins that should get the better part of the deal.

Indeed. What *I'm* trying to do is to find the exact right 
intersections, so you can implement timeline, sequencer and synths as 
normal plugins. I don't see a need for the host to do much more than 
build networks and provide the infrastructure plugins need to 
interact.

Note that this is not the same thing as saying "do it in plugins". No 
one forces you to implement a timeline plugin, or a sequencer plugin. 
In fact, we should really only need one or two of each, and a bunch 
of different UIs for them, to suit all tastes.


//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 ---



More information about the Linux-audio-dev mailing list