[PD] OSC strings and Pd symbols

[Hans-Christoph Steiner]

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.

Yes, I introduce huge changes all the time, and I also manage a bunch of servers to build on and run tests.  I also manually run hours and hours of tests myself.  I also try to get as many people to test my changes as possible, and maintain my own distribution in order to make it easier for people to download and try the code.  I also use beta builds whenever I teach and then work to fix the bugs that come up then.

My time for working on Pd-extended is becoming more and more limited, so I cannot take on any more testing or maintenance.  Indeed I am shedding a lot of stuff because I cannot keep up.  I never use OSC.  I know the current code works well, its been used a lot by a lot of people.  The current "works for me" state of this new commit is very different than the well-tested, widely known state before.

hexloader was removed because it was causing serious problems for many users.  No one wanted to fix those problems, so the choice I had was to leave it or remove it.  Most people don't need or use hexloader, so I chose to remove it.  If someone wants to fix it, it can be added back by default. I don't remember the issues, its in the archives.

So the bottom line is that Pd-extended is successful because it is generally stable and predictable across releases.  That happens because there is a lot of testing and bug fixes.  We are now in a beta state and OSC is essential for a lot of Pd-extended users, so if this is a new feature, and no one is going to do full tests with many people and many programs, this feature should not be included.  If this change is really trivial or a bugfix, then that's different.

.hc


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

As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously.         - Benjamin Franklin