[OSC_dev] floats vs. ints, how to deal

[Julian Rohrhuber]

>James,
>
>I am sorry but I can't agree with you. Why must the receiver to the 
>type conversion and not the sender? (If it is so easy.) I personaly 
>find that the receiver must specifiy the interface (address space, 
>type tags). The sender must comply to this. So any conversion must 
>be done by the sender and all paper work that specifies the 
>interface, by the receiver. When the receiver has a query system, 
>the sender can ask for the interfaces.

For very specific cases this may be appropriate, but in general it is 
much more useful to let the receiver dispatch the message. The type 
tags reveal the meaning of the arguments, they are types of the 
message, not of the receiver implementetion. Then you can send the 
same message to different receivers just as you can ask different 
people "What time is it?" and not "What time is it on your watch?".


>I want to create OSC devices based on microprocessors, so type 
>conversion adds a little bit of unneeded code. It also makes it 
>harder to find errors(bugs) that are releated to the conversion.

maybe a "raw" tag would solve this?

>
>The only reason I see why type tags are useful is monitoring OSC. 
>Most protocols don't have any information about the data, so it is 
>impossible to create a monitor program (like wireshark) that show 
>you human readable data, for any random message it receives. With 
>the type tags it is very easy.
>
>My view in short: Speaker must make sure that the listener can understand him.

Pedagogically I agree. But the process by which this is achieved is 
not so much the listener who tells the speaker what to say or how to 
say it, but an act of interpretation on the side of the listener and 
a reversal of roles.

"The listener, not the speaker determines the meaning of a 
proposition." (Heinz von Foerster)







>Kurt
>
>
>From:  James McCartney <asynth at io.com>
>Reply-To:  "Developer's list for the OpenSound Control (OSC) 
>Protocol"<osc_dev at create.ucsb.edu>
>To:  "Developer's list for the OpenSound Control (OSC) 
>Protocol"<osc_dev at create.ucsb.edu>
>Subject:  Re: [OSC_dev] floats vs. ints, how to deal
>Date:  Sat, 3 Mar 2007 11:17:13 -0800
>>
>>On Feb 11, 2007, at 9:26 PM, Ross Bencina wrote:
>>
>>>Hi Steve
>>>
>>>Interesting problem. As far as I know, OSC doesn't say much about  
>>>this. But personally I think Pd is at least partly wrong -- it  
>>>should probably allow the user to pass a type tag string as a  
>>>parameter.... but chuck should be able to handle messages with ints
>>>  in them too..
>>>
>>>My take on things is that the reciever should be the one who fixes  
>>>the type signature of the message, and the sender should conform to
>>>  this (same logic as for function calls in statically typed  
>>>languages like C, C++, Java etc). Implicit type coercion has never  
>>>been part of the OSC spec, so the idea that the reciever will  
>>>convert numeric types doesn't sit well with me. There's also the  
>>>possibility for "overloaded" messages where the semantics are  
>>>dependent on the type signature.
>>>
>>>Cheers
>>>
>>>Ross.
>>
>>OK I'm a little late on this, but to me the problem is not with Pd.  
>>The point of type tags is to identify to the receiver the type of
>>the  value sent. It is up to the receiver to do a conversion based
>>on the  tag - string integers and floats can all be converted to
>>each other.  The interface should be as polymorphic as possible. For
>>the receiver  to only accept floats is like those web forms that
>>won't accept  spaces or dashes in phone or credit card numbers. lazy
>>programmer!
>>
>>--- james mccartney
>>_______________________________________________
>>OSC_dev mailing list
>>OSC_dev at create.ucsb.edu
>>http://www.create.ucsb.edu/mailman/listinfo/osc_dev
>
>
>
>De meest trendy stuff voor 
><http://g.msn.com/8HMANLBE/2752??PS=47575>Windows Live Messenger ...
>
>_______________________________________________
>OSC_dev mailing list
>OSC_dev at create.ucsb.edu
>http://www.create.ucsb.edu/mailman/listinfo/osc_dev


-- 





.