[PD] OSC strings and Pd symbols

[Hans-Christoph Steiner]

On Mar 21, 2012, at 1:58 PM, Roman Haefeli wrote:

> On Wed, 2012-03-21 at 13:14 -0400, Hans-Christoph Steiner wrote:
>> On Mar 21, 2012, at 12:49 PM, Roman Haefeli wrote:
>> 
>>> On Wed, 2012-03-21 at 12:05 -0400, Hans-Christoph Steiner wrote:
>>>> On Mar 21, 2012, at 5:26 AM, Roman Haefeli wrote:
>>>> 
>>>>> On Tue, 2012-03-20 at 18:21 -0400, Martin Peach wrote:
>>>>>> So I just committed a new [unpackOSC] to svn. 
>>>>> 
>>>>> Cool!
>>>>> 
>>>>>> I don't really have a sure 
>>>>>> way of generating UTF-8 in Pd so someone with a non-US keyboard will 
>>>>>> have to test it. I can do things like the accented e and mu but serious 
>>>>>> symbols end up as something like /u123 if I try to paste them into Pd.
>>>>> 
>>>>> ö ä ü é è à © ▣ ▶ ▦ ◇ ● ñ ♠ 한 국 어 日 本 العربية  বাং ল ިވެހިބަސް 
>>>>> 𐌲  ♩ ♨ 
>>>>> 
>>>>> Those characters seems all to work fine. I can transmit them over OSC
>>>>> from Pd to Pd and display them in symbol box and I can also transmit
>>>>> them between python-liblo and Pd. It looks all good to me.
>>>>> Interestingly, I can also use characters and display them in a symbol
>>>>> box that normally are prohibited by Pd: \ { }
>>>>> 
>>>>> Thanks a lot for this change. I'm all excited about being able to use
>>>>> funny symbols for GUI designing ;-)
>>>> 
>>>> This sounds like a good change but a risky one. 
>>> 
>>> Can you elaborate on that? It does not harm Pd in any way, as we already
>>> figured out. All I implementations of OSC I could find do actually
>>> _support_ UTF-8 (or probably more precise: they do not check at all and
>>> live a happy live).
>>> 
>>>> Since Pd-extended 0.43 is beta, I think it would be best to not
>>>> include it.  What do you think?
>>> 
>>> If you do not include that change, it might happen, that in Pd OSC
>>> messages are dropped that work everywhere else. Why would you
>>> intentionally keep such a situation? If you're concern is about other
>>> OSC applications, then one should prohibit [packOSC] to send UTF-8
>>> strings, but not keeping [unpackOSC] to not support UTF-8.
>>> 
>>> <rant>
>>> You introduce huge changes without hesitation to new versions of
>>> Pd-extended, such as removing flatspace (I agree that it should be
>>> removed, though) or how the preferences dialog works, which obviously
>>> matters for a huge chunk of the user base and which will have huge
>>> implications (see the list archives). However, for - in my eyes -
>>> esoteric reasons you refuse to not include small and tested changes,
>>> that won't affect a lot of the users anyway. Can you explain what
>>> concepts your decisions are based on?
>>> I also remember the case, where you didn't want to make Pd-extended load
>>> hexloader per default, although this would render some libraries such as
>>> iemmatrix and zexy to work right out of the box. What is a worse: a yet
>>> unknown bug in hexloader or to willingly break libraries? Does Pd
>>> support UTF-8 now or not? Do we rely on the fact, that Pd now supports
>>> it? Wouldn't it be a clear bug in Pd, if UTF-8 symbols would cause
>>> troubles, that needs to be fixed anyway?
>>> If you intentionally want to make my life difficult and limit what
>>> projects like netpd can do, please go on and do not include such
>>> changes.
>>> I think it would be better in such situation to trust the people who
>>> actually use the parts of a software affected by changes than not
>>> trusting such changes at all. Otherwise the 'benevolent dictatorship'
>>> becomes an arbitrary one.
>>> </rant>
>> 
>> As far as I understand it, this is a feature, and a somewhat
>> unorthodox use of OSC.  I thought I read that OSC does not officially
>> support anything but ASCII.
> 
> Correct. According to the official specs, the change would add a new
> feature. However, in the real (OSC) world, the suggested change is
> rather a bug-fix.
> 
> Thanks for your detailed statement, btw. Still, I do think that if
> you're after off-loading some of your work, you need to trust others.
> Also I'd like to know what the requirements are for such a change to be
> accepted by you. This is rather opaque to me. I'd be really happy to
> discuss real-world issues that are directly related to a proposed
> change. But in this particular case, I have a hard time seeing what
> serious issues could arise. 


Yes, its true, I do need to try to open up the process of maintaining Pd-extended and not always fallback on feeling burned by the cases were "getting it into Pd-extended" meant "let Hans maintain it".  I'm always open to suggestions as to how to make that happen.

I was asking here because I don't really know the OSC stuff.  If you tell me that this is something that both of you are _sure_ won't break other things in OSC, then I'm fine with it being in Pd-extended.  I would just really hate to see 0.43 be shipping with a broken OSC lib.

.hc


----------------------------------------------------------------------------

Using ReBirth is like trying to play an 808 with a long stick.    -David Zicarelli