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