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
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
hi marius,
umlauts are easy -- no need for any special mechanism, other than lifting the input barrier. Text editor does the job now, and this
#N canvas 211 136 388 253 12; #X text 60 78 ÄÜÖäüöß;
works for me. For other encodings, try cyclonic comments.
Krzysztof
marius schebella wrote: ...
is this the right place to also talk about encoding-format for additional letters (ÄÜÖäüöß...)?
Hi Krzysztof,
yes, but there is no utf encoding line in the pd file. so my ÃÃÃ will look very different in other countries computers... what are cyclonic comments? from which version does the text editor the job? I am still on 0.37.0.
Marius.
Krzysztof Czaja said:
hi marius,
umlauts are easy -- no need for any special mechanism, other than lifting the input barrier. Text editor does the job now, and this
#N canvas 211 136 388 253 12; #X text 60 78 ÃÃÃäüöÃ;
works for me. For other encodings, try cyclonic comments.
Krzysztof
marius schebella wrote: ...
yes, but there is no utf encoding line in the pd file. so my ÄÖÜ will look very different in other countries computers...
right, as for now, one would have to redefine proc pdtk_text_new...
what are cyclonic comments? from which version does the text editor the job?
did not mean Pd's text editor, but editing a .pd file in any text editor proper. Cyclonic comments are [comment] objects from the cyclone library.
Krzysztof
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
On Wed, 24 Mar 2004, Thomas Grill wrote:
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
I am very much aware of that, and it is a bit of a discomfort, because the GridFlow object class name prefix is "@" too (since the beginning, that is, spring of 2001). Frankly I'm not too sure what other prefix it can be, but I want it to be as short as that. I really don't want [@ +] to become as verbose as [jit.op @op +]. And also GridFlow was there before Jitter, so why should I change my stuff. That's quite a bit of a dilemma.
#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.
May I know why attributes have a prefix at all? Is it for distinguishing the end of the main argument list from the attribute list?
BTW GridFlow has something called startup messages, so that this:
[foo bar, hello 37, world 42]
is roughly equivalent to:
[loadbang] | [hello 37, world 42 ( | [foo bar]
except that those messages get sent at the moment the object is created, which is before it gets connected to other objects. This is my way of implementing attributes.
This is very easily implemented without modifications to the patcher format.
I call it modifying the patcher format because the regular Pd will destroy those attributes when they appear in almost any of the standard objects, as well as the patchcords.
PS: for some reason again, i wrote this days ago and forgot to actually send it.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Wed, 24 Mar 2004, Mathieu Bouchard wrote:
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.
.. so this means no changes, right ? Surely a possible extension.
- 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.
You are right, actually most of the arguments that do not form part of the functionality should be key/value pairs.
- 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).
if the {} do not present problems for the tcl/tk interpreter they seem to be the best choice. I am not sure though if pd supports nested lists.
- 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.
I think you would only have to change the parser, and the converter from pd internal types to text representation. This should not introduce changes in too many places.
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.
Sounds good.
- 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...
Considering that the language itself should be kept as simple as possible (everyone is happy that we do not have integer and float types anymore), I think, at least for the user, there should not be a distinction between symbols and strings. Where would we want to have strings ?
Guenter
Mathieu Bouchard http://artengine.ca/matju
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Wed, 24 Mar 2004, guenter geiger wrote:
On Wed, 24 Mar 2004, Mathieu Bouchard wrote:
- "#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.
.. so this means no changes, right ? Surely a possible extension.
It means some changes, because currently, Pd can load a patch in which "#X connect" has 5 or more arguments, BUT it does NOT save back the extra arguments.
if the {} do not present problems for the tcl/tk interpreter they seem to be the best choice.
They don't present problems for Tcl/Tk as long as they are balanced, because then they are exactly matching Tcl/Tk list semantics.
I am not sure though if pd supports nested lists.
Pd does not support nested lists, and isn't quite equipped to support them gracefully. This is partly linked to the fact that objects are expected to treat "float 42" and "list 42" the same way.
In GridFlow this is particularly exacerbated, as you may have to insert [float $1( or [list $1( messageboxes in places to fudge the interpretation of the data. I mean, GridFlow isn't really about nested lists, but its multidimensional lists ("grids") can be thought of as if they were nested lists most of the time. And then this problem appears:
"list 42" is a 1-list -> a 1-dimensional grid of size {1} "float 42" is a scalar -> a 0-dimensional grid of size {}
Are essentially different in GF but the same by Pd, and GF cannot be changed to match Pd, as this is fundamental to handling any-dimensional grids in a clean, uniform manner.
Now back to nested lists... compare the mess.
If they are effectively introduced, it'd probably be by adding T_LIST as an atom type. But that means that, to be like other atom types, a list message would have to have only one argument, of atom type T_LIST. But it probably wouldn't, because of backward compatibility, and so if you happen to have a "list" message containing just a T_LIST, this would be a 1-list containing only another list. Furthermore, you wouldn't be able to just take a "list" message and extract its value as an atom, as that atom would've to be constructed. In a list message, $1 refers to the first element of the list, not the whole list as an atom.
Yet another problem with nested lists is that they require some special memory allocation tricks. I would assume a reference-counting scheme would be appropriate, as a mark+sweep system is more difficult to get right.
I think you would only have to change the parser, and the converter from pd internal types to text representation. This should not introduce changes in too many places.
Cool, I'll try this eventually, though I'm not completely sure how I'll implement nested lists -- or how I'll avoid implementing them...
Considering that the language itself should be kept as simple as possible (everyone is happy that we do not have integer and float types anymore), I think, at least for the user, there should not be a distinction between symbols and strings. Where would we want to have strings ?
Günter, a symboltable is not meant to be used as a textprocessing playground. The way it's used in Pd right now, it's a big gaping glorified developer-approved memory leak. I guess it matters less nowadays, because with average textprocessing needs, even a gallery installation can stay up for weeks and months on a commonplace 512M RAM memory card, and I'm not even talking of swap partitions and swap files. Then the next barrier is the 2560M limit of virtual memory per process... under 32-bit Linux anyway... and I guess buying a 64-bit K8 -- with 16 billion gigs of virtual address space per process -- is easier than fixing a big gaping glorified developer-approved memory leak... :-}
I mean I can hear John McCarthy scream in disgust and abomination... (he invented the symbol type back in 1958...)
If there is too much resistance, I guess I'll continue developing them string features in terms of grids, but currently it's not possible to put a grid inside a list, so you can't do a list of strings of variable lengths, so it sort of sucks too. I guess they could be \0-padded ... I wonder how Jitter's string handling handles this case... if it does at all...
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
hi Mathieu,
iirc the original PureData project was about keeping the max-like message passing system as simple as it was, and designing ``pure data structures'' instead. Has this project died?
If so, Pd should change its name, perhaps?
Krzysztof
Mathieu Bouchard wrote: ...
Pd does not support nested lists, and isn't quite equipped to support them gracefully. This is partly linked to the fact that objects are expected to
...
If they are effectively introduced, it'd probably be by adding T_LIST as an atom type. But that means that, to be like other atom types, a list
On Thu, 1 Apr 2004, Krzysztof Czaja wrote:
hi Mathieu,
iirc the original PureData project was about keeping the max-like message passing system as simple as it was, and designing ``pure data structures'' instead. Has this project died?
If so, Pd should change its name, perhaps?
:) well, i have to admit that I never seriously used the pure data part of PD. Maybe its just a question of trying to work with the data-structures. My understanding is that the lists from the data-structure section are something different than MAX lists, but maybe its just my impression.
Guenter
Krzysztof
Mathieu Bouchard wrote: ...
Pd does not support nested lists, and isn't quite equipped to support them gracefully. This is partly linked to the fact that objects are expected to
...
If they are effectively introduced, it'd probably be by adding T_LIST as an atom type. But that means that, to be like other atom types, a list
I'd love to use data-structures, but not sure where to start...
I find little interest in messing with tcl/tk canvas drawing...
Anyone actually using data structures??
B.
guenter geiger wrote:
On Thu, 1 Apr 2004, Krzysztof Czaja wrote:
hi Mathieu,
iirc the original PureData project was about keeping the max-like message passing system as simple as it was, and designing ``pure data structures'' instead. Has this project died?
If so, Pd should change its name, perhaps?
:) well, i have to admit that I never seriously used the pure data part of PD. Maybe its just a question of trying to work with the data-structures. My understanding is that the lists from the data-structure section are something different than MAX lists, but maybe its just my impression.
Guenter
Krzysztof
Mathieu Bouchard wrote: ...
Pd does not support nested lists, and isn't quite equipped to support them gracefully. This is partly linked to the fact that objects are expected to
...
If they are effectively introduced, it'd probably be by adding T_LIST as an atom type. But that means that, to be like other atom types, a list
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Thu, 1 Apr 2004, Krzysztof Czaja wrote:
iirc the original PureData project was about keeping the max-like message passing system as simple as it was, and designing ``pure data structures'' instead. Has this project died?
I don't know what is meant here by "pure data structures". Any hints? Maybe I should have gone through the whole tutorial instead of just seeing Pd as a jMax replacement...
If so, Pd should change its name, perhaps?
Well, I already chose Impure Data. It sounds so... postdigital. ;-)
On Thu, 1 Apr 2004, guenter geiger wrote:
:) well, i have to admit that I never seriously used the pure data part of PD. Maybe its just a question of trying to work with the data-structures. My understanding is that the lists from the data-structure section are something different than MAX lists, but maybe its just my impression.
I'll look into it real soon now, but I haven't gone thru the tutorial yet, not enough time. ;-)
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Thu, 1 Apr 2004, Mathieu Bouchard wrote:
.. so this means no changes, right ? Surely a possible extension.
It means some changes, because currently, Pd can load a patch in which "#X connect" has 5 or more arguments, BUT it does NOT save back the extra arguments.
Yes, thats true. I meant in terms of compatibility. But of course, the problem is that editting a patch with more connect arguments in the standard pd version would remove all of the additional information.
I think you would only have to change the parser, and the converter from pd internal types to text representation. This should not introduce changes in too many places.
Cool, I'll try this eventually, though I'm not completely sure how I'll implement nested lists -- or how I'll avoid implementing them...
I skipped the nested lists part. Do not have any idea myself, probably its better to avoid them for now until we have a better picture.
Considering that the language itself should be kept as simple as possible (everyone is happy that we do not have integer and float types anymore), I think, at least for the user, there should not be a distinction between symbols and strings. Where would we want to have strings ?
G�nter, a symboltable is not meant to be used as a textprocessing playground.
I understand your reasoning, but pd is not a text processing language either. Anyhow, probably there is a solution to the problem by introducing a garbage collection for the symbol table, or destroying unused symbols explicitly.
The way it's used in Pd right now, it's a big gaping glorified developer-approved memory leak. I guess it matters less nowadays, because with average textprocessing needs, even a gallery installation can stay up for weeks and months on a commonplace 512M RAM memory card, and I'm not even talking of swap partitions and swap files. Then the next barrier is the 2560M limit of virtual memory per process... under 32-bit Linux anyway... and I guess buying a 64-bit K8 -- with 16 billion gigs of virtual address space per process -- is easier than fixing a big gaping glorified developer-approved memory leak... :-}
I mean I can hear John McCarthy scream in disgust and abomination... (he invented the symbol type back in 1958...)
If there is too much resistance, I guess I'll continue developing them string features in terms of grids, but currently it's not possible to put a grid inside a list, so you can't do a list of strings of variable lengths, so it sort of sucks too. I guess they could be \0-padded ... I wonder how Jitter's string handling handles this case... if it does at all...
I don't really know if I am resisting, it all depends on the implementation of strings, and how they should be handled from the users point of view. If you look at the users list, the standard pd user doesn't want to make a distinction between symbol "hello" and string "hello". I think this should be hidden.
Guenter
On Thu, 1 Apr 2004, guenter geiger wrote:
I understand your reasoning, but pd is not a text processing language either.
And then what? It's not a video processing language either, and it's not an opengl processing language either, and guess what, people use it like that. Can't it handle text processing properly now?...
Anyhow, probably there is a solution to the problem by introducing a garbage collection for the symbol table, or destroying unused symbols explicitly.
Which garbage collection algorithm do you recommend? BTW we prolly can't just scan through atoms because t_symbol*'s may be taken away from their origin.
Destroying unused symbols explicitly allows the user to crash Pd if the unused symbols aren't really unused.
If you look at the users list, the standard pd user doesn't want to make a distinction between symbol "hello" and string "hello". I think this should be hidden.
I wonder whether it's even possible to hide this and keep any kind of backwards compatibility at once...
Btw, to add to the difficulty of backwards compatibility, the symbols are not data-abstracted, so externals just access the ->s_name, AND as well, externals may check for T_SYMBOL when they are trying to differentiate between floats and symbols, so even though atom_getsymbol on a string could intern the string and return that, it would get thrown as unknown type T_STRING before reaching that point. I don't quite know what to do.
I think the solution looks pretty much like introducing strings with explicit casting to symbol... except that this sort of implies doublequotes will be used to denote symbols, and strings would have to use another character.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Wed, 24 Mar 2004, smoerk wrote:
why not drop the old format and use something like XML?
why drop the old format? and why XML? what does it buy us? i suppose you have reasons for suggesting XML so I'd like to know them.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
Because the file format is the same as the pd message format. So you would lose the "Pure Data"ness of Pd by having the file format different than pd messages. I suppose you could make pd messages also be XML, but that would take away the simplicity.
.hc
On Wednesday, Mar 24, 2004, at 11:11 America/New_York, smoerk wrote:
why not drop the old format and use something like XML?
Mathieu Bouchard wrote:
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:
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hans-Christoph Steiner wrote:
Because the file format is the same as the pd message format. So you would lose the "Pure Data"ness of Pd by having the file format different than pd messages. I suppose you could make pd messages also be XML, but that would take away the simplicity.
okay, that makes sense. i find the .pd files hard to read and i thought it makes more sense to store the patches in a more common format. but if this makes things more complicated, it's a stupid idea...
On Wednesday, Mar 24, 2004, at 11:11 America/New_York, smoerk wrote:
why not drop the old format and use something like XML?
Mathieu Bouchard wrote:
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:
-
B. Bogart -
guenter geiger -
Hans-Christoph Steiner -
Krzysztof Czaja -
marius schebella -
Mathieu Bouchard -
smoerk -
Thomas Grill