Fw: [PD-dev] extending the .pd format

[Thomas Grill]

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 at gmx.net>
To: "Mathieu Bouchard" <matju at sympatico.ca>; <pd-dev at 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 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
> >
> >
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>
>