[PD] OSC strings and Pd symbols

Roman Haefeli reduzent at gmail.com
Wed Mar 21 18:58:00 CET 2012


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. 

Roman 





More information about the Pd-list mailing list