[Dev] 'get' revisited

[Henrik Sundt]

>> > I do agree that it's not strictly necessary, except that I think maybe
>> > it's more semantically explicit to use "get".
>> > Personally (in some non-Integra work) I've been using /get with an
>> > argument to specify a timer interval at which the value should be
>> > auto-reported.
>> >
>>
>> OK, I can see that this is a good reason for using a 'get' message.
>> Perhaps this is something that should be considered for the OSC protocol
>> spec...
>>
> Just to make sure we're talking about the same thing. There is no reason
> why we cannot use the '/get' address for a module. The question is do we
> need a '.get' sub-address.
> ...

The reason I put ".get" instead of "/get" in the original protocol
specification, is that the "OSC-route" object for Max/MSP from Berkley
does not accept both having an argument to an address, like "/position 10"
and a subaddress like "/position/get". Having an OSC-route-tree with a
"/position" at first level, and then a "/get" on second level, will output
an error if you input 10 as an argument at the first level.

The solution I found for this was to use "/position 10" and
"/position.get", which both would exist on the same parse level in the
OSC-route tree. But of cource, a sub-address of the form "/get" is much
better in a logical sense.

I don't know whether the Berkley objects has a mis-implementation of the
OSC protocol, or if the mix of arguments and sub-adresses is not allowed
in the OSC protocol itself. According to Alexander Jensenius, "/get" works
fine in the Jamoma implementations of an OSC-rolute object. I have not had
time to investigate this further yet, but maybe some of you might have the
correct answer.

Best,
Henrik S