[PD] Unescaped commas in Pd 0.45 files

[Roman Haefeli]

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.