Hi all
Nowadays, Pd supports UTF-8 and it's possible to type non-ASCII characters into a symbol box (or a message box, if you like). This is generally good thing. When working with [packOSC], every symbolic (non-number) element is treated automagically as a OSC string (unless you create type-forced OSC messages). This generally is also a good thing. The OSC specification states that OSC strings must only contain ASCII characters (which I find a real PITA). As a patch writer, however, I have no measure to make sure, that only pure ASCII symbols are sent to [packOSC].
Currently, the situation is that [packOSC] happily creates invalid (according to the specification) OSC strings, but only [unpackOSC] complains about it when receiving such a string. The error in the console:
unpackOSC: PrintTypeTaggedArgs: Type tag said this arg is a string but it's not!
I don't know what the best solution is to deal with that problem. Strictly sticking to the specification, [packOSC] shouldn't package Pd symbols containing non-ASCII chars into OSC strings in the first place or at least it should chop them off. Another way to deal with it would be to make [packOSC] and [unpackOSC] both support UTF-8 strings instead of ASCII-only strings. In other words, those classes would support an 'extended' OSC string type, which is fully compatible with the 'strict' OSC string type. This also would remove any constraints put on the kind of Pd symbols that can be used as OSC strings. Some (many/most?) other OSC implemenations are _not_ strict in that they do not check if the OSC strings only contain ASCII strings. I checked pyliblo and pyOSC and both allow to transmit deutsche Umlaute in strings. I don't know if there are also strict implementations.
The current behaviour of [packOSC] and [unpackOSC] is IMHO the least favorable, in that it still allows to create 'invalid' OSC strings (possibly causing troubles with strict non-Pd receivers), but complains about them on reception.
Any thoughts on this are welcome.
Roman
Hey Martin
Do you have an opinion on this? Would it do any harm if [packOSC] and [unpackOSC] would allow UTF-8 in strings?
Roman
On Tue, 2012-03-13 at 11:08 +0100, Roman Haefeli wrote:
Hi all
Nowadays, Pd supports UTF-8 and it's possible to type non-ASCII characters into a symbol box (or a message box, if you like). This is generally good thing. When working with [packOSC], every symbolic (non-number) element is treated automagically as a OSC string (unless you create type-forced OSC messages). This generally is also a good thing. The OSC specification states that OSC strings must only contain ASCII characters (which I find a real PITA). As a patch writer, however, I have no measure to make sure, that only pure ASCII symbols are sent to [packOSC].
Currently, the situation is that [packOSC] happily creates invalid (according to the specification) OSC strings, but only [unpackOSC] complains about it when receiving such a string. The error in the console:
unpackOSC: PrintTypeTaggedArgs: Type tag said this arg is a string but it's not!
I don't know what the best solution is to deal with that problem. Strictly sticking to the specification, [packOSC] shouldn't package Pd symbols containing non-ASCII chars into OSC strings in the first place or at least it should chop them off. Another way to deal with it would be to make [packOSC] and [unpackOSC] both support UTF-8 strings instead of ASCII-only strings. In other words, those classes would support an 'extended' OSC string type, which is fully compatible with the 'strict' OSC string type. This also would remove any constraints put on the kind of Pd symbols that can be used as OSC strings. Some (many/most?) other OSC implemenations are _not_ strict in that they do not check if the OSC strings only contain ASCII strings. I checked pyliblo and pyOSC and both allow to transmit deutsche Umlaute in strings. I don't know if there are also strict implementations.
The current behaviour of [packOSC] and [unpackOSC] is IMHO the least favorable, in that it still allows to create 'invalid' OSC strings (possibly causing troubles with strict non-Pd receivers), but complains about them on reception.
Any thoughts on this are welcome.
Roman
Hi Roman,
I'll look into implementing that. I don't see what harm it could do.
Martin
On 2012-03-20 04:58, Roman Haefeli wrote:
Hey Martin
Do you have an opinion on this? Would it do any harm if [packOSC] and [unpackOSC] would allow UTF-8 in strings?
Roman
On Tue, 2012-03-13 at 11:08 +0100, Roman Haefeli wrote:
Hi all
Nowadays, Pd supports UTF-8 and it's possible to type non-ASCII characters into a symbol box (or a message box, if you like). This is generally good thing. When working with [packOSC], every symbolic (non-number) element is treated automagically as a OSC string (unless you create type-forced OSC messages). This generally is also a good thing. The OSC specification states that OSC strings must only contain ASCII characters (which I find a real PITA). As a patch writer, however, I have no measure to make sure, that only pure ASCII symbols are sent to [packOSC].
Currently, the situation is that [packOSC] happily creates invalid (according to the specification) OSC strings, but only [unpackOSC] complains about it when receiving such a string. The error in the console:
unpackOSC: PrintTypeTaggedArgs: Type tag said this arg is a string but it's not!
I don't know what the best solution is to deal with that problem. Strictly sticking to the specification, [packOSC] shouldn't package Pd symbols containing non-ASCII chars into OSC strings in the first place or at least it should chop them off. Another way to deal with it would be to make [packOSC] and [unpackOSC] both support UTF-8 strings instead of ASCII-only strings. In other words, those classes would support an 'extended' OSC string type, which is fully compatible with the 'strict' OSC string type. This also would remove any constraints put on the kind of Pd symbols that can be used as OSC strings. Some (many/most?) other OSC implemenations are _not_ strict in that they do not check if the OSC strings only contain ASCII strings. I checked pyliblo and pyOSC and both allow to transmit deutsche Umlaute in strings. I don't know if there are also strict implementations.
The current behaviour of [packOSC] and [unpackOSC] is IMHO the least favorable, in that it still allows to create 'invalid' OSC strings (possibly causing troubles with strict non-Pd receivers), but complains about them on reception.
Any thoughts on this are welcome.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
So I just committed a new [unpackOSC] to svn. 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.
Martin
On 2012-03-20 04:58, Roman Haefeli wrote:
Hey Martin
Do you have an opinion on this? Would it do any harm if [packOSC] and [unpackOSC] would allow UTF-8 in strings?
Roman
On Tue, 2012-03-13 at 11:08 +0100, Roman Haefeli wrote:
Hi all
Nowadays, Pd supports UTF-8 and it's possible to type non-ASCII characters into a symbol box (or a message box, if you like). This is generally good thing. When working with [packOSC], every symbolic (non-number) element is treated automagically as a OSC string (unless you create type-forced OSC messages). This generally is also a good thing. The OSC specification states that OSC strings must only contain ASCII characters (which I find a real PITA). As a patch writer, however, I have no measure to make sure, that only pure ASCII symbols are sent to [packOSC].
Currently, the situation is that [packOSC] happily creates invalid (according to the specification) OSC strings, but only [unpackOSC] complains about it when receiving such a string. The error in the console:
unpackOSC: PrintTypeTaggedArgs: Type tag said this arg is a string but it's not!
I don't know what the best solution is to deal with that problem. Strictly sticking to the specification, [packOSC] shouldn't package Pd symbols containing non-ASCII chars into OSC strings in the first place or at least it should chop them off. Another way to deal with it would be to make [packOSC] and [unpackOSC] both support UTF-8 strings instead of ASCII-only strings. In other words, those classes would support an 'extended' OSC string type, which is fully compatible with the 'strict' OSC string type. This also would remove any constraints put on the kind of Pd symbols that can be used as OSC strings. Some (many/most?) other OSC implemenations are _not_ strict in that they do not check if the OSC strings only contain ASCII strings. I checked pyliblo and pyOSC and both allow to transmit deutsche Umlaute in strings. I don't know if there are also strict implementations.
The current behaviour of [packOSC] and [unpackOSC] is IMHO the least favorable, in that it still allows to create 'invalid' OSC strings (possibly causing troubles with strict non-Pd receivers), but complains about them on reception.
Any thoughts on this are welcome.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 ;-)
Roman
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. Since Pd-extended 0.43 is beta, I think it would be best to not include it. What do you think?
.hc
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
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
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
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
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, 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.
.hc
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
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
-
Billy Stiltner -
Hans-Christoph Steiner -
Martin Peach -
Roman Haefeli