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