[PD] Unescaped commas in Pd 0.45 files

[Miller Puckette]

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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list