Re: num/denom v's double (was: Re: [LAD] [ANN] LV2 beta3)

On Fri, 2007-05-11 at 22:36 +0100, Steve Harris wrote:
> On 11 May 2007, at 20:37, Fons Adriaensen wrote:
>
> > On Fri, May 11, 2007 at 06:24:38PM +0100, Steve Harris wrote:
> >
> >> On 11 May 2007, at 15:07, Fons Adriaensen wrote:
> >
> >>> Two 32-bit ints can represent (the non-integer part of) most (not
> >>> all)
> >>> irrational values to better precision than a double. The algo to
> >>> find
> >>> them is a bit mysterious but very simple. Simple example: 355/113 is
> >>> equal to pi with a relative error of less than 1e-7, not bad for two
> >>> 3-digit numbers. It's not difficult to find two 32-bit ints that
> >>> would
> >>> be better than a double.
> >
> > First, if you read the paragraph above in its context, it should be
> > clear that this is *not* the rationale for having sample rates as
> > a ratio of two integers. It's just a side note.
> >
> > (Sigh) I have already written (some nights ago) that this has nothing
> > to do with _absolute_ precision. Most sound cards are way off their
> > nominal sample rate anyway, and very few people complain.
> >
> > This is about _relative_ precision in multirate processing. It only
> > works if the ratios are exact. It does not work at all if they are
> > not. I can easily imagine processing networks where not all plugins
> > run at the same rate, but at rates related by simple integer ratios.
> > Maybe improbable for music production. But certainly possible for
> > audio DSP work in general.
>
> I see. So that's the point that I missed. Here, I think the
> difference of opinion is that I don't think LADSPA-style APIs are at
> all appropriate for multirate audio - the LADSPA API was built very
> much with input sample rate = output sample rate in mind. I think
> that any move away from that will complicate the API, when a better
> solution would be to use a different API altogether.

I'm not so sure I agree with that; you /could/ do multirate with LV2.
Yes, it's more complicated, but no more complicated than multirate audio
via any other API (other than the slight un-prettyness of having a
single hardcoded sample rate parameter).

Anyway, there's no doubt that the basic plugin API shouldn't be made
more complicated by this esoteric need, so agreed there. As with
everything else, that bridge can be crossed when someone gets there...

-DR-

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Received on Sat May 12 08:15:03 2007