Hi all
Pd's file format has changed since 0.45 as a new feature was introduced that lets you set the width for all boxes and comments. The object width is saved in the patch by using an yet unused mechanism. Before, an ordinary message box was stored like this:
#X msg 93 110 bla;
Now since 0.45, when the width of the object has been manually altered, the line looks like this:
#X msg 93 110 bla, f 35;
This un-escaped comma does not comply with the FUDI protocol as used by many other object classes like [netsend]/[netreceive] or [textfile]. Before that change, Pd files could be treated as fully FUDI compliant. It was possible to use [textfile] to read and process Pd files. After saving, those files were still functional Pd files. Since the new feature, Pd files cannot be processed in the same manner. A message box as defined above results in:
#X msg 93 110 bla; f 35;
The resulting Pd file is corrupt and cannot be parsed by Pd anymore. I considered it a great advantage that the same protocol was used consistently throughout Pd. Though it might not have been an advertised feature, it made a lot of sense to me and I've been exploiting it.
netpd now suffers from that new feature because it uses [textfile] to read and transfer patches between clients. Any patch that was made in Pd 0.45 and uses manually altered object widths breaks horribly when transferred. Miller suggested to use the newly introduced [text] object instead [1]. It allows to export a bunch of FUDI messages (or a Pd file, so to speak) as one single list. Regarding the problem above, that surprisingly even works for Pd files that use the new feature. The problem I face is that OSC packets have a maximum size and some Pd files are too large to fit into one OSC packet. I could split them up, but with lists there is no way to tell how many bytes they are using (you can only measure the number of atoms).
I'm writing to the list to raise awareness of the issue. As 0.45 is still fresh, the new format may not be yet carved in stone. It might also be the case that I'm the only one who cares. Well, scrap it then.
Roman
[1] Check that out if you haven't already. It opens up a lot of new ways to deal with texts in Pd. I think it is an excellent new object! Thanks, Miller.
Well, perhaps this would be a workaround at least: you could catch lists strting with the symbol 'f' and prepend "#X" to them, thus:
#X msg 93 110 bla; #X f 35;
(But perhaps there's some reason you can't filter the messages... I don't know al lthe ins and outs of how netpd sends patches around :)
M
On Sun, Jan 26, 2014 at 01:14:23PM +0100, Roman Haefeli wrote:
Hi all
Pd's file format has changed since 0.45 as a new feature was introduced that lets you set the width for all boxes and comments. The object width is saved in the patch by using an yet unused mechanism. Before, an ordinary message box was stored like this:
#X msg 93 110 bla;
Now since 0.45, when the width of the object has been manually altered, the line looks like this:
#X msg 93 110 bla, f 35;
This un-escaped comma does not comply with the FUDI protocol as used by many other object classes like [netsend]/[netreceive] or [textfile]. Before that change, Pd files could be treated as fully FUDI compliant. It was possible to use [textfile] to read and process Pd files. After saving, those files were still functional Pd files. Since the new feature, Pd files cannot be processed in the same manner. A message box as defined above results in:
#X msg 93 110 bla; f 35;
The resulting Pd file is corrupt and cannot be parsed by Pd anymore. I considered it a great advantage that the same protocol was used consistently throughout Pd. Though it might not have been an advertised feature, it made a lot of sense to me and I've been exploiting it.
netpd now suffers from that new feature because it uses [textfile] to read and transfer patches between clients. Any patch that was made in Pd 0.45 and uses manually altered object widths breaks horribly when transferred. Miller suggested to use the newly introduced [text] object instead [1]. It allows to export a bunch of FUDI messages (or a Pd file, so to speak) as one single list. Regarding the problem above, that surprisingly even works for Pd files that use the new feature. The problem I face is that OSC packets have a maximum size and some Pd files are too large to fit into one OSC packet. I could split them up, but with lists there is no way to tell how many bytes they are using (you can only measure the number of atoms).
I'm writing to the list to raise awareness of the issue. As 0.45 is still fresh, the new format may not be yet carved in stone. It might also be the case that I'm the only one who cares. Well, scrap it then.
Roman
[1] Check that out if you haven't already. It opens up a lot of new ways to deal with texts in Pd. I think it is an excellent new object! Thanks, Miller.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Oh, interesting. This works very well. Many thanks for the hint. I'm going to use that for now.
I only figured now, that a construct like this is still parsed correctly by Pd:
#X msg 93 110 bla, f 35, msg 93 130 blu, f 20;
(This creates two messages boxes)
I only understand now, that Pd makes a clear distinction between ';' and ',' when parsing patch files. [textfile] on the other hand seems to treat both the same. One bang outputs data until the next comma OR semicolon. So my statement that Pd files are not FUDI compliant in Pd 0.45 is somewhat unqualified. [netreceive] behaves similar to Pd's parser. It flushes only when it receives a semicolon, but not on a comma. However, if the flushed buffer contains unescaped commas, it is sent as several messages. One could argue that the correct behaviour of [textfile] should be similar: When banged, it should output everything until the next semicolon. If that data contains commas, it is sent as several messages. The lack of distinction by [textfile] is actually the source my initial problem. But if reading files with [textfile] would behave "correctly", writing would still be an issue: How should [textfile] know wether to use ';' or ',' to terminate incoming lists?
Roman
On Son, 2014-01-26 at 09:05 -0800, Miller Puckette wrote:
Well, perhaps this would be a workaround at least: you could catch lists strting with the symbol 'f' and prepend "#X" to them, thus:
#X msg 93 110 bla; #X f 35;
(But perhaps there's some reason you can't filter the messages... I don't know al lthe ins and outs of how netpd sends patches around :)
M
On Sun, Jan 26, 2014 at 01:14:23PM +0100, Roman Haefeli wrote:
Hi all
Pd's file format has changed since 0.45 as a new feature was introduced that lets you set the width for all boxes and comments. The object width is saved in the patch by using an yet unused mechanism. Before, an ordinary message box was stored like this:
#X msg 93 110 bla;
Now since 0.45, when the width of the object has been manually altered, the line looks like this:
#X msg 93 110 bla, f 35;
This un-escaped comma does not comply with the FUDI protocol as used by many other object classes like [netsend]/[netreceive] or [textfile]. Before that change, Pd files could be treated as fully FUDI compliant. It was possible to use [textfile] to read and process Pd files. After saving, those files were still functional Pd files. Since the new feature, Pd files cannot be processed in the same manner. A message box as defined above results in:
#X msg 93 110 bla; f 35;
The resulting Pd file is corrupt and cannot be parsed by Pd anymore. I considered it a great advantage that the same protocol was used consistently throughout Pd. Though it might not have been an advertised feature, it made a lot of sense to me and I've been exploiting it.
netpd now suffers from that new feature because it uses [textfile] to read and transfer patches between clients. Any patch that was made in Pd 0.45 and uses manually altered object widths breaks horribly when transferred. Miller suggested to use the newly introduced [text] object instead [1]. It allows to export a bunch of FUDI messages (or a Pd file, so to speak) as one single list. Regarding the problem above, that surprisingly even works for Pd files that use the new feature. The problem I face is that OSC packets have a maximum size and some Pd files are too large to fit into one OSC packet. I could split them up, but with lists there is no way to tell how many bytes they are using (you can only measure the number of atoms).
I'm writing to the list to raise awareness of the issue. As 0.45 is still fresh, the new format may not be yet carved in stone. It might also be the case that I'm the only one who cares. Well, scrap it then.
Roman
[1] Check that out if you haven't already. It opens up a lot of new ways to deal with texts in Pd. I think it is an excellent new object! Thanks, Miller.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Miller Puckette -
Roman Haefeli