[PD] Unescaped commas in Pd 0.45 files

Roman Haefeli reduzent at gmail.com
Sun Jan 26 21:01:38 CET 2014


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





More information about the Pd-list mailing list