wow!
is this the right place to also talk about encoding-format for additional letters (ÃÃÃäüöÃ...)?
marius.
----- Original Message ----- From: "Mathieu Bouchard" matju@sympatico.ca To: pd-dev@iem.kug.ac.at Sent: Wednesday, March 24, 2004 7:30 AM Subject: [PD-dev] extending the .pd format
Hi, I would need some input on extending the .pd format. I would also like that some modifications get made to Pd to support extensibility. Here's the plan for now:
- "#X connect" lines would take any number of extra arguments, which
would have to be preserved by attaching an atom list to each connection and save that list when saving the connection. Ideally this would have to be put in all versions of Pd. Now, miller+devel branches may actually just ignore those extra arguments, and the impd branch would do something else with it.
- all GUI objects should support additional arguments in pretty much the
same way.
- Alternately, (1) and (2) can be replaced by having a new #-code (like
#E standing for extra) that applies to the last #X. This would be especially good for adding properties to GUI objects that already have a use for any number of arguments (messageboxes, objectboxes themselves, and comments).
- In any case, I think it would be good to have those extras as key/value
pairs, because 23 unnamed arguments (#X obj 0 0 vsl blah blah blah) is already a bit hard to follow sometimes, and it sounds silly to me to add more of those unnamed arguments, especially since in most cases, default values still would be used, just like they already are in the case of half of the 23 unnamed arguments right now.
- There's a problem with the above idea (4) when it comes to counting a
list as a value. One way to resolve this is to introduce sublists, which would be a good idea anyway, and use the {} characters (that are currently dropped, and so unused) for that purpose, just like how they are used in jMax2 and Tcl already (or parens in LISP, or [] in many others).
- However I don't know how much code would have to be changed for (5) to
be completed. If I didn't care about compatibility, I would introduce {}'s all over the place, but if I have to make it easier for other (miller+devel) branches, then i'd ask to only support them in #E's for now, and delay their other potential uses in the rest of Pd (inside normal "#X obj" arguments, etc), though using parens with spaces around them (in GF/Pd) still looks silly anytime.
Ok, the above are my most important ideas, but below are some extra nonneglectible ideas that I'm less sure what to do about.
- If doublequotes changed meaning to quoting symbols in pretty much
C/Tcl/etc allow, it would be an incompatibility, but I suspect the end result of most of the affected patches would actually remain the same, just going through different semantics, such that "foo bar" would just be a 7-character symbol instead of two 3-character symbols.
- However I would prefer doublequotes to mean _string literals_ instead,
and maybe use some other character for symbol quoting: LISP uses [], but LISP isn't too familiar to most Pd users anyway. I might suggest backticks or singlequotes. String literals might be difficult to introduce neatly into Pd, because it would be great if they could be used (magically) instead of symbols whenever possible, and have automatic conversion, but I guess all the code checking for T_SYMBOL won't support it...
Mathieu Bouchard http://artengine.ca/matju
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev