Re: [linux-audio-dev] [RFC] Lite OSC API

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] [RFC] Lite OSC API
From: rd_AT_alphalink.com.au
Date: Mon Jan 26 2004 - 17:58:20 EET


> an integer in scheme? Couldnt the problem be solved by specifying
> the type explicitly at send time and doing the coercion then? eg:
>
> (->  "/foo"  "isf" 100  "hello" 100.0)

That is exactly what would be required and it is not at all good.  People
in user space should not have to even know that there are single and
double precision floating point representations in order to set the
frequency of an instrument.  Especially not from a language
environment where the distinction does not even exist!  And it will afflict
not only Lisps and dialects but SmallTalks and dialects and MLs and
dialects and so on.  I don't know the Patcher dialects but I imagine
things would be as bad if not worse.

It loses straight up for variable arity messages, (apply ->  "/n_setn" node
0 data-from-somewhere).

And even from C like languages users still need to *remember* for
every OSC message they ever want to send whether '/frequency' is
required as a single or double precision real number, and whether
'/midi-note' is required as a 'c' integer, an 'i' integer, an 'f' float, or a 'd'
double, all of which are reasonable requirements for different
implemntations.  

It means that if two synths have a '/global-gain' controller you might need
to format two different OSC packets to tell them to be quiet [one with a 'f'
zero and one with a 'd' zero].  

It means that if a synth implementor decides that the '/phase' input really
should be double precision she cannot change the request type from
the library because it will break *every existing user* of her synth!  Their
single precision phase values are no longer good enough?  Surely at
this point the implementor will probably just fix the library to do type
coercion or find another library...

In the redundant case the coercion adds one integer comparison to the
dispatch path per argument, and thoughtful ordering of the coercion
table should get most common cases in two or three comparisons; it is
not an expensive operation.  

And I am still arguing that it is an important aspect of OSC that when a
synth advertises a '/freq' message, users can be confident that sending
it 440, whether encoded as a 32bit or 64bit integer, or as a 32bit or 64bit
float, will likely tune the synth to A440.  OSC is in user space, I think it
would be a pity if synths advertised '/freqi', '/freqh', '/freqf' and '/freqd'
messages in an attempt to help users out.

Regards,
Rohan


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jan 26 2004 - 17:59:10 EET