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. > > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
