[PD] OSC strings and Pd symbols

[Roman Haefeli]

On Wed, 2012-03-21 at 14:13 -0400, Hans-Christoph Steiner wrote:
> 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,

Frankly, how can someone absolutely sure. I'd say it is very unlikely.
The maintainer of the osc library is Martin and if he agrees, I wouldn't
see a reason not to include it.
 
>  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.

Yeah, totally. Before that change, it could easily happen, that in Pd an
OSC message was composed that never reached the receiver (also in Pd) ,
because the OSC message contained a Pd symbol with non-ASCII chars. The
change fixes this situation with a kind of work-around that complies
with other OSC implementations (but not with the official spec). IMHO,
the obvious gain (a broken situation got fixed) outweighs the negligible
chance of introducing new problems and why I think it is rather safe to
be included in Pd-extended. 

Roman