Subject: Re: [linux-audio-dev] One API for everything (first draft)
From: Simon Per Soren Kagedal (simon_AT_cs.uoregon.edu)
Date: Fri Jun 01 2001 - 02:20:35 EEST
Hi all,
I've been reading through a lot of LAD recently and it has been very
enjoyable, thank you. Here is a point that bothered me that I did not
see anyone else address:
On Sat, May 19, 2001 at 01:28:19PM -0400, Paul Davis wrote:
> >I can think of no reason to deal with samples in any format other than
> >floats. Previously the use of MMX might have been compelling, but now all
>
> as long as we include the possibilty of "float" having a compile-time
> switch to mean either 32 or 64 bit floats, I agree. but only compile
> time. there should be no support for any format other than whatever
> "float" format was chosen at compile time.
This I don't like. If there are situations where 64 bit floats are
really needed in inter-app communication, then it should be available
for everyone, not just compiler-enabled people, so to speak. The
audio pro who wants extra precision isn't necessarily a skilled
computer user. Sure, distributions could package seperately
"laaga-32", "laaga-64", "ardour-32", "ardour-64" etc., but that is
obviously not nice. What happens if someone tries to run someprog-64
with their ardour-32? Horrible crashes and/or noises, probably.
I'm all for small and neat interfaces, but if there will be different
kinds of audio data in some situations, *some* kind of runtime type
compatibility check will be needed - and as I understood from another
of your (Paul's) mail, you want some kind of type on the ports anyway
(for future extensibility, MIDI etc..) So, I know this topic has been
discussed on and on, I apologize if I'm just bringing it up again
without anything new to offer, but what is so horribly evil about a
small type on every port, and if they don't match then you get a
polite error message? No implicit conversion, no negotiation.
The default type could be 32-bit float (or actually - whatever "float"
was set to compile time, that I think is acceptable!), adding 0 extra work
for the 95% of plugin programmers. The other 5% of course need a
little bit more work. Am I missing something?
Thanks,
Simon.
This archive was generated by hypermail 2b28 : Fri Jun 01 2001 - 03:00:24 EEST