[gmpi] Re: Decision Time: 8.3
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 15 Sep 2003 14:53:46 -0700
On Sun, Sep 14, 2003 at 10:42:46AM +0100, Steve Harris wrote:
On Sat, Sep 13, 2003 at 11:38:17 -0700, Tim Hockin wrote:
> What of platforms that do not have FPUs?
They still have libm, but I guess its an unnessary expense.
Another alternative would be to make it that same format as a sample (ala
LADSPA). Assuming we do go for a single sample format.
That's kinda what I was thinking.
I see a need for
float - many normal params
double - high res params
Could those two be collapsed into just one or the other? Smells a
bit redundant from a parameter perspective.
int - many normal params
enum - radio buttons, N-position knobs
bool - buttons
string - filenames, words
blob - misc
Yes, I like all these, at least as the semantic types. As you say
below, they can share the same binary reps in most cases, but I like
keeping the semantics separated at the parameter spec level. Better
clarity for users.
Now, float can be translated to be the same as sample_type. I'm not sure
how thinsg that require double-precision can be translated into non-FPU.
This whole non-FPU thing is a real pain in the ass.
<aside>
I want to make a motion that we NOT consider systems without FPUs, or that
we find some simpler way to handle it. Perhaps those non-FPU platforms
don't have to do FP audio IO, but _do_ need to do float/double parameters?
What is the real goal of non-FPU support? Where are it's backers? Whenever
someone says something that might make non-FPU systems hurt, no one speaks
up for them. Are we solving a problem that doesn't exit?
</aside>
Int parameters can be faked using float.
Enum and bool can be faked using int.
Yep..
String and Blob are obvious, I think.
Maybe. Length encoded and/or null terminated? Starts
word/doubleword aligned, or arbitrary byte address? ASCII characters
only, or Unicode support? Max possible length? Etc. So in many
ways int, float, double are far more obvious.
So that leaves my NEED list at float/real/sample_type + string + blob. Are
there good reasons to turn anything else into fundamental primitives?
Perhaps int - can anyone justify it?
Yeah, to avoid unnecessary conversions. I mean, by that logic, since
you can encode any int or float/double number as a (long enough)
sequence of ASCII characters, so why use anything other than string?
-- Chris G.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
