[PD] OSC strings and Pd symbols

[Roman Haefeli]

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>

Roman