Hi all
The Pd file format might have its flaws, but I always enjoyed the fact that Pd files can be parsed with on-board tools like [textfile]. Using the same format (FUDI) for networking, file I/O, message passing makes a lot of things easier.
Pd 0.45 is introducing a new feature to control width for objects/messages/comments. The way it is implemented breaks the ability to parse Pd files with [textfile]. The reason is that the format uses an un-escaped comma to delimit the object arguments from the object font/width properties.
The following shows the original file data and after it has been sent from [textfile] to another and then saved:
orig:
#N canvas 613 117 450 300 10; #X floatatom 39 54 10 0 0 0 - - -, f 10; #X msg 122 145 f 31 , f 31, f 37;
the same 'parsed' by [textfile]:
#N canvas 613 117 450 300 10 #X floatatom 39 54 10 0 0 0 - - - f 10 #X msg 122 145 f 31 , f 31 f 37
I don't know any solution off-hand and I also don't know whether Pd was designed with the possibility in mind to read patches with [textfile]. I just want to have it mentioned. And yes, it does break some of my patches (not that this would be a reason not go forward and change Pd's file format).
Roman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-29 15:43, Roman Haefeli wrote:
I don't know any solution off-hand and I also don't know whether Pd was designed with the possibility in mind to read patches with [textfile]. I just want to have it mentioned. And yes, it does break some of my patches (not that this would be a reason not go forward and change Pd's file format).
since my personal preferences for those "," appendices to objects go into the direction of using them for messages that the object itself can understand(e.g. #X obj 100 100 readsf~, open foo.wav; ) i'd rather vote for keeping "meta"-messages (e.g. those that tell the GUI-renderer which color the object should have) separate.
e.g. #X obj 100 100 readsf~; #G width 10;
oh btw, i really don't see a reason to use cryptic 'f' selectors, when we could use meaningful names like "width".
fgamsdr IOhannes
On Mon, 2013-07-01 at 15:04 +0200, IOhannes m zmoelnig wrote:
On 2013-06-29 15:43, Roman Haefeli wrote:
I don't know any solution off-hand and I also don't know whether Pd was designed with the possibility in mind to read patches with [textfile]. I just want to have it mentioned. And yes, it does break some of my patches (not that this would be a reason not go forward and change Pd's file format).
since my personal preferences for those "," appendices to objects go into the direction of using them for messages that the object itself can understand(e.g. #X obj 100 100 readsf~, open foo.wav;
Those uses would not interfere with each other as your example would actually read:
#X obj 100 100 readsf~, open foo.wav;
(mind the backslash)[1].
Also, the escaped commas do not cause any troubles for Pd file parsing. It's only the new non-escaped commas that do.
) i'd rather vote for keeping "meta"-messages (e.g. those that tell the GUI-renderer which color the object should have) separate.
e.g. #X obj 100 100 readsf~; #G width 10;
Yeah, why not? This wouldn't break anything, at least.
oh btw, i really don't see a reason to use cryptic 'f' selectors, when we could use meaningful names like "width".
Agreed.
What is Miller's stance on this?
Roman
On 07/01/2013 09:04 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-29 15:43, Roman Haefeli wrote:
I don't know any solution off-hand and I also don't know whether Pd was designed with the possibility in mind to read patches with [textfile]. I just want to have it mentioned. And yes, it does break some of my patches (not that this would be a reason not go forward and change Pd's file format).
since my personal preferences for those "," appendices to objects go into the direction of using them for messages that the object itself can understand(e.g. #X obj 100 100 readsf~, open foo.wav; ) i'd rather vote for keeping "meta"-messages (e.g. those that tell the GUI-renderer which color the object should have) separate.
e.g. #X obj 100 100 readsf~; #G width 10;
I second that vote, and also vote to never actually implement #G: * as I've never seen a request for the feature of having a bunch of differently colored object boxes in a patch * since specifying width doesn't solve the problem of making arbitrary line breaks in comments without using a semicolon * since specifying width can be done with a method for comments * since the number of classes that create inside an object box and which would benefit from resizable widths can be counted on no fingers * since specifying gui props with commas separated methods in an object box allows the _user_ to specify both gui and state properties without lifting their hands from the keyboard:
[vsl, label look_ma_no_mouse, label_pos 20 20, size...]
-Jonathan
oh btw, i really don't see a reason to use cryptic 'f' selectors, when we could use meaningful names like "width".
fgamsdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlHRfl0ACgkQkX2Xpv6ydvRhVwCg6Rc8o/AGHKAmYAjOxuxXE0SG uEoAoLe4cy6BEikkMIsytCFRFi294cPm =WYqL -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Just to stir the pot, as it were :) -
The 'f' message is intended to mean 'format' and could be expanded to specify font style and size, and/or other formatting info (perhaps even to suppress carriage return on semi, think of that!)
cheers Miller
On Wed, Jul 03, 2013 at 02:48:30AM -0400, Jonathan Wilkes wrote:
On 07/01/2013 09:04 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-29 15:43, Roman Haefeli wrote:
I don't know any solution off-hand and I also don't know whether Pd was designed with the possibility in mind to read patches with [textfile]. I just want to have it mentioned. And yes, it does break some of my patches (not that this would be a reason not go forward and change Pd's file format).
since my personal preferences for those "," appendices to objects go into the direction of using them for messages that the object itself can understand(e.g. #X obj 100 100 readsf~, open foo.wav; ) i'd rather vote for keeping "meta"-messages (e.g. those that tell the GUI-renderer which color the object should have) separate.
e.g. #X obj 100 100 readsf~; #G width 10;
I second that vote, and also vote to never actually implement #G:
- as I've never seen a request for the feature of having a bunch of
differently colored object boxes in a patch
- since specifying width doesn't solve the problem of making
arbitrary line breaks in comments without using a semicolon
- since specifying width can be done with a method for comments
- since the number of classes that create inside an object box and
which would benefit from resizable widths can be counted on no fingers
- since specifying gui props with commas separated methods in an object
box allows the _user_ to specify both gui and state properties without lifting their hands from the keyboard:
[vsl, label look_ma_no_mouse, label_pos 20 20, size...]
-Jonathan
oh btw, i really don't see a reason to use cryptic 'f' selectors, when we could use meaningful names like "width".
fgamsdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlHRfl0ACgkQkX2Xpv6ydvRhVwCg6Rc8o/AGHKAmYAjOxuxXE0SG uEoAoLe4cy6BEikkMIsytCFRFi294cPm =WYqL -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-07-03 17:58, Miller Puckette wrote:
Just to stir the pot, as it were :) -
The 'f' message is intended to mean 'format' and could be expanded to specify font style and size, and/or other formatting info (perhaps even to suppress carriage return on semi, think of that!)
hmm, how about calling it.. "format" then?
there are quite a number of "f"s in Pd world, and i think every single one means "float".
(or maybe even use "__format" to mark it as a 'private' message)
fgmasdr IOhannes
On Mit, 2013-07-03 at 08:58 -0700, Miller Puckette wrote:
Just to stir the pot, as it were :) -
The 'f' message is intended to mean 'format' and could be expanded to specify font style and size, and/or other formatting info (perhaps even to suppress carriage return on semi, think of that!)
In order to prepare myself for the future: Do you intend to keep the un-escaped comma to separate box content from format data?
Roman
On Wed, Jul 03, 2013 at 09:09:26PM +0200, Roman Haefeli wrote:
On Mit, 2013-07-03 at 08:58 -0700, Miller Puckette wrote:
Just to stir the pot, as it were :) -
The 'f' message is intended to mean 'format' and could be expanded to specify font style and size, and/or other formatting info (perhaps even to suppress carriage return on semi, think of that!)
In order to prepare myself for the future: Do you intend to keep the un-escaped comma to separate box content from format data?
Roman
It's a hack. I'm thinking about someday building it into the regular "obj" etc. messages - but this would require making up all new names for those messages which would make backwards compatibility tricky. So for the next while at least I think the trailing message is the way to go.
cheers Miller
-
IOhannes m zmoelnig -
Jonathan Wilkes -
Miller Puckette -
Roman Haefeli