[PD-dev] extending the .pd format

[Mathieu Bouchard]

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:

1. "#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.

2. all GUI objects should support additional arguments in pretty much the
same way.

3. 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).

4. 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.

5. 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).

6. 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.



7. 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.

8. 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