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

[Steve Harris]

On Tue, Jan 27, 2004 at 12:59:30 +1100, rd at alphalink.com.au wrote:
> > OK, interesting - it wouldn't be a huge task, but why is this a good 
> idea? 
> > It just seems inconvienient for the recipient and I dont know of any 
> other 
> > RPC mechanisms where its allowed (or wanted). In the case of 
> typetag-less 
> > messages it would be difficult to handle, you'd have to try to discover 
> > the type of the argument by inspection. Do you have a link to a 
> rationale 
> > for this? 
> 
> Firstly, from the horses mouth, "non-type-tagged messages [are] totally 
> deprecated".  See 
> <http://www.create.ucsb.edu/pipermail/osc_dev/2003-November/00032
> 9.html> and surrounding posts.  I don't think you need to even try to think 
> about possibly considering perhaps partially supporting such things!

Good :))
 
> Secondly, it is actually no work for the receiver.  The receiver says that is 
> needs a signed 32bit integer and it gets such an integer.  It is a little 
> work for the library.  On the other hand it can be a lot of work for the 
> sender.  Domain specific languages often do not implement full C like 
> numerical towers, a signal processing language could easily only 
> implement floating point numbers, Lua famously has only double 
> precision floating point numbers, and lots of people use Lua.  

Thats only true if thier using the engine to do the type conversion for
them, if thier doing it by hand then its going to need a lot of switch
(cond?) statements.
 
> Since I think this is really important I will give an example, and from the 
> other end of a continuum.   I use scheme for most of my music work.  
> Scheme has a very sophisticated numerical tower.  I might write (-> 
> "/n_set" 1001 "freq" 440) to set the frequency of an instrument at SC3.  
> The OSC encoder encodes values based on their lisp type, 1001 is an 
> integer and gets encoded as 'i'.  Lets assume that to the receiver the 
> frequency argument is a float, here I lose because 440 is an integer.  I 
> argue that a receiver implemented like that is just wrong, that an integer 
> 440 frequency is completely valid, and SC3 thankfully agrees and plays 
> the right note.  
>
> However if you disagree and say that I should write the literal as a float 
> then that makes scheme a hopeless language to work in, 440.0 is still 
> an exact integer, I need to write #i440 to get an inexact integer.  But the 
> situation is far worse, if I write (* m 1.5) this seems like it should make 
> an inexact value regardless where m arrives from, however scheme 
> knows that (* 0 1.5) is an exact zero and I lose again, it may even know 
> that (* 2 1.5) == (* 2 3/2) == 3, an exact integer .  Forcing a user to _very_ 
> carefully annotate _all_ code that might get sent as an OSC packet 
> _only because_ the OSC receiver cannot accept exact integers is not 
> going to work, I just won't be able to work with the process.   SC3 gets 
> this very right, as usual, and in fact allows:

OK, I see your problem, but its just further convinced me that scheme is
not a nice language ;) [I never liked lisp].

How far do you want to take the conversion? Do strings get converted to
float? Timestamps? Perl could easily get confused and send 1.0 as "1.0" or
vice versa if you weren't careful.
 
> > > * not allocate any memory or call any other non-RT safe procedure 
> > This one is inherantly not possible, youre doing i/o operations. 
> 
> Well actually it is only doing the byte encoding.  SC3, being dragged out 
> for yet another example, allows users to link in the synthesis engine and 
> push OSC packets directly onto a queue, thus avoiding any IPC 
> operations but still using an identical communication protocol.  For the 
> liblo case you are of course correct, but the temporal behaviour of the 
> encoder/decoder can be pretty predictable.

Yes, true.
 
> > I've always been more of a strongly-typed guy :) 
> 
> Me too, we schemers all are, we just think that an exact integer is a real 
> number :)

Did you get that the wrong way round? I though to problem was that 1.0 was
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)

- Steve