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

[rd at alphalink.com.au]

> 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