[PD] OSC strings and Pd symbols

[Martin Peach]

Hi Roman,

I'll look into implementing that. I don't see what harm it could do.

Martin

On 2012-03-20 04:58, Roman Haefeli wrote:
> Hey Martin
>
> Do you have an opinion on this? Would it do any harm if [packOSC] and
> [unpackOSC] would allow UTF-8 in strings?
>
> Roman
>
>
> On Tue, 2012-03-13 at 11:08 +0100, Roman Haefeli wrote:
>> Hi all
>>
>> Nowadays, Pd supports UTF-8 and it's possible to type non-ASCII
>> characters into a symbol box (or a message box, if you like). This is
>> generally good thing.
>> When working with [packOSC],  every symbolic (non-number) element is
>> treated automagically as a OSC string (unless you create type-forced OSC
>> messages). This generally is also a good thing.
>> The OSC specification states that OSC strings must only contain ASCII
>> characters (which I find a real PITA). As a patch writer, however, I
>> have no measure to make sure, that only pure ASCII symbols are sent to
>> [packOSC].
>>
>> Currently, the situation is that [packOSC] happily creates invalid
>> (according to the specification) OSC strings, but only [unpackOSC]
>> complains about it when receiving such a string. The error in the
>> console:
>>
>> ---
>> unpackOSC: PrintTypeTaggedArgs: Type tag said this arg is a string but it's not!
>> ---
>>
>> I don't know what the best solution is to deal with that problem.
>> Strictly sticking to the specification, [packOSC] shouldn't package Pd
>> symbols containing non-ASCII chars into OSC strings in the first place
>> or at least it should chop them off.
>> Another way to deal with it would be to make [packOSC] and [unpackOSC]
>> both support UTF-8 strings instead of ASCII-only strings. In other
>> words, those classes would support an 'extended' OSC string type, which
>> is fully compatible with the 'strict' OSC string type. This also would
>> remove any constraints put on the kind of Pd symbols that can be used as
>> OSC strings.
>> Some (many/most?) other OSC implemenations are _not_ strict in that they
>> do not check if the OSC strings only contain ASCII strings. I checked
>> pyliblo and pyOSC and both allow to transmit deutsche Umlaute in
>> strings. I don't know if there are also strict implementations.
>>
>> The current behaviour of [packOSC] and [unpackOSC] is IMHO the least
>> favorable, in that it still allows to create 'invalid' OSC strings
>> (possibly causing troubles with strict non-Pd receivers), but complains
>> about them on reception.
>>
>> Any thoughts on this are welcome.
>>
>> Roman
>>
>>
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->  http://lists.puredata.info/listinfo/pd-list
>
>