[PD-dev] extending the .pd format

[Thomas Grill]

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 at sympatico.ca>
To: <pd-dev at 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:
>
> 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
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>
>