And, btw., i'd like to emphasize that a standardized escape or quoting mechanism for Umlauts and symbols with spaces would be very much appreciated.
best greetings, Thomas
----- Original Message ----- From: "Thomas Grill" t.grill@gmx.net To: "Mathieu Bouchard" matju@sympatico.ca; pd-dev@iem.kug.ac.at Sent: Wednesday, March 24, 2004 10:35 AM Subject: Re: [PD-dev] extending the .pd format
Hi Mathieu, i don't know if you are aware of the way extra information is handled in Max/Jitter and also flext. There, the format is as follows
#X object arg1 arg2 arg3... @key1 val1... @key2 val2.... @key3 val3 .... etc.
The key-value pairs are known as "attributes", with the @ of course being
a
reserved symbol. This is very easily implemented without modifications to the patcher
format.
best greetings, Thomas
----- 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
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev