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

[rd at alphalink.com.au]

> 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!

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.  

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:

(-> "/n_set" #i1000 (exact->inexact 0) 440)

The node and index values at SC3 are syntactically integers (the index 
can also be a string name that maps to an integer), and the argument is 
syntactically a float, but it accepts floating point encodings of integers 
and integer encodings of real values.  SC3 does it like this, QED :)

> I agree that combining the verb and subject seems a little odd, but that 
> is the sitatuion in the web services world too - when neccesary they 
get 
> round it by adding a verb argument eg ("/my/path", "verb", ...), which is 
> a useful cnvention but its not neccesary to set it in stone. 

I think the real question is, does anyone really want to do pattern 
matching on the operator?  I have never seen a convincing example.  It 
would introduce all sorts of really strange sequencing issues to start 
with...  The pattern matching people seem to like is usually of the form 
("/instr[1-4]/freq" 440), not ("/instr1/{freq,ampl}" 330).  If you restrict the 
matching to the subject, make the subject an argument, and make the 
operator the OSC address then the OSC dispatch mechanism can be 
reasonably efficient, which matters in RT synthesis environments, and 
people who want RE descriptors for subjects can do that without 
imposing an onerous burden on the core dispatch mechanism.  And it 
looks better!  In fact it looks comfortingly like lisp, ("/freq" "/instr[1-4]" 550) 
:-\

> > * 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.

> 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 :)

Regards,
Rohan