|
From: Stephen S. <rad...@gm...> - 2013-03-25 20:55:47
|
On Mon, Mar 25, 2013 at 4:44 PM, Camille Troillard <ca...@os...> wrote: > Hi Steve, > > > On 25 mars 2013, at 21:15, Stephen Sinclair <rad...@gm...> wrote: > >> On the other hand automatically truncating floats to int doesn't >> necessarily make sense in most cases. More problematically, I would >> guess that registering an 'i' and then an 'f' handler would cause the >> 'i' handler to always be called, instead of matching on 'i' or 'f' as >> you might expect. >> >> Personally I would consider it a bit dangerous to have very different >> semantics associated with a message depending on the type of its >> arguments, but on the other hand I do find the automatic coercion a >> bit of a hazard to be aware of. > > Yes. In the case I had in mind, I want to define OSC API that uses integers only. Floats would not make sense, so I understand I should discard any message that has different types than those that were defined with the handler. It seems it can be done easily by testing strcmp on the typespec argument of the handler callback. Sure, I guess that could work. A bit ugly :( I'm not really against an API addition to turn off coercion. I've already added a set of option flags for lo_address, something similar for lo_server might make sense. > In another use-case, the float and int values have different but close semantics. Float are considered as normalized values (0.0 to 1.0) and integers as absolute values (depending on the range, for example 0 to 127). So yeah, there's a case where you should be aware of the Pd / Max behaviour.. if that's an intended usage scenario anyways. Steve |