Hallo list!
I know this topic was discussed ago, but as I was thinking about PD and XML I (maybe) wanna make an external for saving and opening PD patches as XML files.
The advantages of XML would be (as anyone of you knows): - PD patches could be merged into the CVS - it would be easy to write PD-patches in a XML editor (so e.g. it also would be possible for blind people to write PD-patches - and at least in Graz I know a blind man who wants to try PD ...) - could be displayed in browsers with different style sheets - (and of course many more ...)
So I made a first simple example for now - just to start the discussion (if anyone is interested):
---------original-patch------------------------ #N canvas 828 549 450 341 10; #X obj 49 134 print; #X msg 49 45 bang; #X obj 49 105 f 2; #X connect 1 0 2 0; #X connect 2 0 0 0; -----------------------------------------------
---------in-xml-------------------------------- <canvas xpos="828" ypos="549" height="450" width="341">
<obj ID="obj0" xpos="49" ypos="134"> print </obj> <msg ID="msg0" xpos="49" ypos="45"> bang </msg> <obj ID="obj1" xpos="49" ypos="105"> f 2 </obj> <!-- should 2 be an extra tag for init arg ? -->
<connect> <outlet ID="msg0"> 0 </outlet> <!-- is this good? --> <inlet ID="obj1"> 0 </inlet> </connect> <connect> <outlet ID="obj1"> 0 </outlet> <inlet ID="obj0"> 0 </inlet> </connect>
</canvas> -----------------------------------------------
short explanation: every object or message gets an ID and with that ID it's possible to connect all the objects - but it's only a first trial.
LG Georg
On Thu, 9 Dec 2004, Georg Holzmann wrote:
The advantages of XML would be (as anyone of you knows):
- PD patches could be merged into the CVS
[...]
<outlet ID="msg0"> 0 </outlet> <!-- is this good? -->
[...]
short explanation: every object or message gets an ID and with that ID it's possible to connect all the objects - but it's only a first trial.
Ok, you're exactly not solving the problem of merging in CVS. That problem is that object ID's change too often, because if an object is deleted, its ID is not skipped, and a bunch of objects are renumbered just so that the ID is not skipped, because there is no way in the format to skip one. I think this has to be solved in the pd internals first, in the runtime storage of a patch, because it's where the renumbering (or the ignoring of numbering) normally happens. Then that change can be propagated to the writing in either .xml or a slightly extended version of .pd; and there could be a save-option that would renumber objects so that the .pd file is compatible with older pd's. The new .pd format would have a directive like this:
#S 42;
where 42 means to increment the object counter by 42 without creating new objects, so that the "#X connect" lines stay the same as much as possible.
would be possible for blind people to write PD-patches - and at least in Graz I know a blind man who wants to try PD ...)
Let me guess: his name is Mario ? A month after the convention I recalled that I had met online a guy called Mario from Graz several years earlier, but I didn't know PureData back then.
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Mathieu Bouchard wrote:
problem is that object ID's change too often, because if an object is deleted, its ID is not skipped, and a bunch of objects are renumbered just so that the ID is not skipped, because there is no way in the format to skip one. I think this has to be solved in the pd internals first, in the runtime storage of a patch, because it's where the renumbering (or the ignoring of numbering) normally happens.
This might be a good time to introduce the Globally Unique Identifer, perhaps in the form of a 32-bit random number that is generated for each object in a patch and never reused -- the running pd program would maintain a list of all GUIDs in use in the current session. The same approach could be used with the externs, in order to discriminate among externs with the same name, but this requires a central repository and registration system...
Martin
On Thu, 9 Dec 2004, Martin Peach wrote:
Mathieu Bouchard wrote:
problem is that object ID's change too often, because if an object is deleted, its ID is not skipped, and a bunch of objects are renumbered just so that the ID is not skipped, because there is no way in the format to skip one. I think this has to be solved in the pd internals first, in the runtime storage of a patch, because it's where the renumbering (or the ignoring of numbering) normally happens.
This might be a good time to introduce the Globally Unique Identifer, perhaps in the form of a 32-bit random number that is generated for each object in a patch and never reused -- the running pd program would maintain a list of all GUIDs in use in the current session.
Well, I was thinking of something along the lines of a locally unique identifier, whose scope is exactly one patcher, because the problem with changing indices happens exactly at the patcher level. I don't know what GUID's would bring at this point. I can't think of any nice way of introducing GUID's easily in the .pd format except by making each object two lines of code instead of one. What do you have in mind?
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Hi, something like GUIDs would be great, but i think they should be somehow readable (not Microsoft-like). What about a running index per patcher, that is incremented every time an object is created? Or a date/time/microtime combination? For me the integration into the PD file format is not important since there's no real place for other metadata either. A discussion about a general XML format is really appreciated.
best greetings, Thomas
----- Original Message ----- From: "Mathieu Bouchard" matju@sympatico.ca To: "Martin Peach" martinrp@vax2.concordia.ca Cc: "Georg Holzmann" grhPD@gmx.at; pd-dev@iem.at Sent: Friday, December 10, 2004 10:48 AM Subject: Re: [PD-dev] PD patches in XML
On Thu, 9 Dec 2004, Martin Peach wrote:
Mathieu Bouchard wrote:
problem is that object ID's change too often, because if an object is deleted, its ID is not skipped, and a bunch of objects are renumbered
just
so that the ID is not skipped, because there is no way in the format
to
skip one. I think this has to be solved in the pd internals first, in
the
runtime storage of a patch, because it's where the renumbering (or the ignoring of numbering) normally happens.
This might be a good time to introduce the Globally Unique Identifer, perhaps in the form of a 32-bit random number that is generated for each object in a patch and never reused -- the running pd program would maintain a list of all GUIDs in use in the current session.
Well, I was thinking of something along the lines of a locally unique identifier, whose scope is exactly one patcher, because the problem with changing indices happens exactly at the patcher level. I don't know what GUID's would bring at this point. I can't think of any nice way of introducing GUID's easily in the .pd format except by making each object two lines of code instead of one. What do you have in mind?
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Thomas Grill wrote:
something like GUIDs would be great, but i think they should be somehow readable (not Microsoft-like).
A 32-bit number should be sufficient: 0x00000000 to 0xFFFFFFFF allows for more than 4 billion objects in a patch.
What about a running index per patcher, that is incremented every time an object is created?
Yes, that's faster than generating a random number and then checking for duplicates.
Or a date/time/microtime combination?
If objects are never created simultaneously within the resolution of the clock...It's still faster just to increment a variable than to query the system clock.
Martin
On Fri, 10 Dec 2004, Martin Peach wrote:
Thomas Grill wrote:
something like GUIDs would be great, but i think they should be somehow readable (not Microsoft-like).
A 32-bit number should be sufficient: 0x00000000 to 0xFFFFFFFF allows for more than 4 billion objects in a patch.
What about a running index per patcher, that is incremented every time an object is created?
Yes, that's faster than generating a random number and then checking for duplicates.
Well, if a hashtable is used for the duplicates, and any fast half-believably-random number generator is used, then this solution is sufficiently fast, even for an underclocked 80286.
The real reason that random numbers may be less appropriate is that it makes a .pd (or .pd-xml) patch look more noisy. Which is not sooo much of an issue either, but still more so than "performance".
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On a side note, something like this, or improvements along these lines, I think would greatly improve the ability to do dynamic patching. Right now it's difficult to do connects with messages because I have no idea what number each object is. (Or maybe there's a more straightforward solution to this particular issue?)
Best, Ian
Thomas Grill wrote: | Hi, | something like GUIDs would be great, but i think they should be somehow | readable (not Microsoft-like). | What about a running index per patcher, that is incremented every time an | object is created? | Or a date/time/microtime combination? | For me the integration into the PD file format is not important since | there's no real place for other metadata either. | A discussion about a general XML format is really appreciated. | | best greetings, | Thomas | | ----- Original Message ----- | From: "Mathieu Bouchard" matju@sympatico.ca | To: "Martin Peach" martinrp@vax2.concordia.ca | Cc: "Georg Holzmann" grhPD@gmx.at; pd-dev@iem.at | Sent: Friday, December 10, 2004 10:48 AM | Subject: Re: [PD-dev] PD patches in XML | | | |>On Thu, 9 Dec 2004, Martin Peach wrote: |> |>>Mathieu Bouchard wrote: |>> |>>>problem is that object ID's change too often, because if an object is |>>>deleted, its ID is not skipped, and a bunch of objects are renumbered | | just | |>>>so that the ID is not skipped, because there is no way in the format | | to | |>>>skip one. I think this has to be solved in the pd internals first, in | | the | |>>>runtime storage of a patch, because it's where the renumbering (or the |>>>ignoring of numbering) normally happens. |>> |>>This might be a good time to introduce the Globally Unique Identifer, |>>perhaps in the form of a 32-bit random number that is generated for each |>>object in a patch and never reused -- the running pd program would |>>maintain a list of all GUIDs in use in the current session. |> |>Well, I was thinking of something along the lines of a locally unique |>identifier, whose scope is exactly one patcher, because the problem with |>changing indices happens exactly at the patcher level. I don't know what |>GUID's would bring at this point. I can't think of any nice way of |>introducing GUID's easily in the .pd format except by making each object |>two lines of code instead of one. What do you have in mind? |> |>_____________________________________________________________________ |>Mathieu Bouchard -=- Montréal QC Canada -=- 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
Ian Smith-Heisters wrote:
On a side note, something like this, or improvements along these lines, I think would greatly improve the ability to do dynamic patching. Right now it's difficult to do connects with messages because I have no idea what number each object is. (Or maybe there's a more straightforward solution to this particular issue?)
I once wrote a max external (world) that would output its pointer, which other dynamically created externals (agents) could then use to directly access the world storage. (Then the world object would display the agents). Straightforward but behind the scenes.
Using the object's pointer as its ID would be useful this way. Also we talked about this a while ago as the meaning of $0 in a message, so that sending [$0( to an object wuld cause it to output its pointer.
Martin
On Fri, 10 Dec 2004, Martin Peach wrote:
Using the object's pointer as its ID would be useful this way. Also we talked about this a while ago as the meaning of $0 in a message, so that sending [$0( to an object wuld cause it to output its pointer.
I reiterate that $0 ought to be substituted in a messagebox message for the selector of the message that triggered the messagebox.
Eg. sending 42 to [foo $0( would generate "foo float", and sending "bang" would generate "foo bang".
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
On Fri, 10 Dec 2004, Thomas Grill wrote:
something like GUIDs would be great, but i think they should be somehow readable (not Microsoft-like). What about a running index per patcher, that is incremented every time an object is created?
That's my idea. It can be either a new number each time, or the smallest integer that is not currently used.
Or a date/time/microtime combination?
Why?
For me the integration into the PD file format is not important since there's no real place for other metadata either.
I proposed a #S directive for skipping id's, supposing they still get assigned starting at 0, and they are still incremented at every object construction, and #S takes care of telling where the gaps are. This is only a small (incompatible) addition to the .pd format, but it would make .pd files diffable and patchable (really).
A discussion about a general XML format is really appreciated.
Why?
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
A discussion about a general XML format is really appreciated.
Why?
Because then we would not have to think about inventing strange additions to the PD format to store any kind of structured metadata. Maybe you don't need it, but i'm sure some people do.
best greetings, Thomas
Mathieu Bouchard wrote:
On Thu, 9 Dec 2004, Martin Peach wrote:
Mathieu Bouchard wrote:
problem is that object ID's change too often, because if an object is deleted, its ID is not skipped, and a bunch of objects are renumbered just so that the ID is not skipped, because there is no way in the format to skip one. I think this has to be solved in the pd internals first, in the runtime storage of a patch, because it's where the renumbering (or the ignoring of numbering) normally happens.
When an object is deleted, maybe it could be replaced with a null object? At the moment if I insert a line like: #X obj; pd crashes (on Windows at least). I think pd could be made more robust at the same time by using null objects as placeholders.
This might be a good time to introduce the Globally Unique Identifer, perhaps in the form of a 32-bit random number that is generated for each object in a patch and never reused -- the running pd program would maintain a list of all GUIDs in use in the current session.
Well, I was thinking of something along the lines of a locally unique identifier, whose scope is exactly one patcher, because the problem with changing indices happens exactly at the patcher level. I don't know what GUID's would bring at this point. I can't think of any nice way of introducing GUID's easily in the .pd format except by making each object two lines of code instead of one. What do you have in mind?
Well actually three levels of ID: Lowest level are LUIDs, but in the sense of a GUID: a locally unique identifier for each object in a patcher, e.g. 0x00000001 (sequential) or 0x132FA32B (pseudorandom). LUIDs would need an extra field in the .pd format line, (maybe use #X12345678 instead of #X) so it's not backwards compatible (maybe after the semicolon(?)). The proposed XML format is easily extensible because parsers would just ignore tags they don't recognize. Another LUID could identify each patcher, so objects in one patcher could target objects in another. (#N9ABCDEF0 instead of #N ?) Finally a GUID would be reserved for 'published' objects that were registered, say at the pd-iem site or sourceforge, so that a patcher would always use the correct objects even (the nightmare scenario ;() if every pd object had the same name.
Martin
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
On Fri, 10 Dec 2004, Martin Peach wrote:
On Thu, 9 Dec 2004, Martin Peach wrote:
Mathieu Bouchard wrote:
When an object is deleted, maybe it could be replaced with a null object? At the moment if I insert a line like: #X obj; pd crashes (on Windows at least). I think pd could be made more robust at the same time by using null objects as placeholders.
Yeah, crashes here as well. I tried empty comments, which turn into "comment" upon loading, and i tried backslash space comments, which turn into empty comments upon saving. No other ideas.
LUIDs would need an extra field in the .pd format line, (maybe use #X12345678 instead of #X) so it's not backwards compatible (maybe after the semicolon(?)).
Pd patches are free-form, so the semicolon is the true terminator, and newlines only count as regular whitespace. A newline is not required after the semicolon.
Another LUID could identify each patcher, so objects in one patcher could target objects in another.
Why? there is already [s] and [r], there is already send-symbols and receive-symbols that make things more complicated, and then you'd enjoy making connections between objects _across_ patchers ??
Finally a GUID would be reserved for 'published' objects that were registered, say at the pd-iem site or sourceforge, so that a patcher would always use the correct objects even (the nightmare scenario ;() if every pd object had the same name.
I think it would be important to distinguish clearly between "object" and "class" before starting to talk on that kind of topic.
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
just some comments...
Georg Holzmann wrote:
---------in-xml--------------------------------
<canvas xpos="828" ypos="549" height="450" width="341">
<obj ID="obj0" xpos="49" ypos="134"> print </obj> <msg ID="msg0" xpos="49" ypos="45"> bang </msg> <obj ID="obj1" xpos="49" ypos="105"> f 2 </obj> <!-- should 2 be an extra tag for init arg ? -->
i think this inherits a bit the weaknesses of pd's standard format.
which is: mixing up functionality (object-name), modifiers (arguments) and graphical representation (position). i would rather seperate them as much as possible, something like
<canvas> <gui xpos="828" ypos="549" height="450" width="341"> <obj ID="obj1"> f <args>2</args> <gui xpos="49" ypos="134"> </obj> <obj ID="obj2"> trigger <args>float float</args> <gui xpos="49" ypos="134" bgcolor="#FF00FF"> </obj> </canvas>
or even worse, breaking lists of arguments into several tags:
<canvas> <gui xpos="828" ypos="549" height="450" width="341"> <obj ID="obj2"> trigger <arg>float</arg> <arg>b</arg> <gui xpos="49" ypos="134" bgcolor="#FF00FF" width="100"> </obj> </canvas>
(some things are not implemented yet in pd...)
as with pd-0.38, objects that pd's not able to create still connect (i guess with some wild hack that tracks the highest number of connected outlets of an object) this could also be done simply by giving meta-information such as <obj ID="obj10" inlets="1" outlets="4">foo</obj>
<connect> <outlet ID="msg0"> 0 </outlet> <!-- is this good? --> <inlet ID="obj1"> 0 </inlet> </connect> <connect> <outlet ID="obj1"> 0 </outlet> <inlet ID="obj0"> 0 </inlet> </connect> </canvas>
well i am not at all into XML (so i do not know which restrictions you can put into a validator) but i guess this syntax is very prone for things like <connect> <outlet ID="obj1">0</outlet> <outlet ID="obj2">1</outlet> </connect>
how could you avoid this ? (connecting 2 outlets)
i think mathieus rejections are not valid within this context:: it is not clear from your example (because it is short), but: object-identifiers ("ID") should be unique identifiers, at least within the scope of a (canvas-) tag. ID's should be able to be chosen arbitrarily, so this would be a valid patch:
<canvas> <msg ID="foo">bang</msg> <obj ID="bar">print</obj> <connect> <outlet ID="foo" n="0"/> <inlet ID="bar" n="1"/> </connect> <obj ID="obj9">until</obj> <connect> <outlet ID="foo" n="0"/> <outlet ID="obj9" n="1"/> </connect> </canvas>
pd could give ID's automaticaly, most probably with a counter (like "obj0", "obj1", "obj2",...) on deletion of such an object the ID would be lost, but who cares ? people that are writing patches in a text-editor could choose whatever ID they like (but have to make sure, that it is unique)
another question that arises for me is, whether it is really good to separate strictly between objects (and messages) and connections, or whether connections are just part of objects. something like
<obj ID="foo">print</obj> <msg ID="bar"> bang <connect n="0"> <inlet ID="foo" n="0"> <gui color="red">comment</gui> </connect> </msg>
this is just a wild suggestion, having not thought clearly about whether it is better to connect bottom-up or top-down (probably allow both in addition to distince <connect>-tags that are free-flowing)
as for the index-naming mechanism: i do not think that anyone should bother whether this is fast or slow; most likely (if you don't decide to use something very stupid as the base for the ID-mechanism) it is way faster than the gensym() that needs to be called for each object that gets created; so lets skip premature optimization
mfg.as.dr IOhannes
Hallo!
i think this inherits a bit the weaknesses of pd's standard format. which is: mixing up functionality (object-name), modifiers (arguments) and graphical representation (position).
yep!
i would rather seperate them as much as possible, something like
<canvas> <gui xpos="828" ypos="549" height="450" width="341"> <obj ID="obj1"> f <args>2</args> <gui xpos="49" ypos="134"> </obj> <obj ID="obj2"> trigger <args>float float</args> <gui xpos="49" ypos="134" bgcolor="#FF00FF"> </obj> </canvas>
okay, maybe it's clearer to use a own tag for all the gui properties. So we can also easy expand these GUI-descriptions (e.g. for IEM-GUIs etc.).
as with pd-0.38, objects that pd's not able to create still connect (i guess with some wild hack that tracks the highest number of connected outlets of an object)
good to know ...
this could also be done simply by giving meta-information such as <obj ID="obj10" inlets="1" outlets="4">foo</obj>
well i am not at all into XML (so i do not know which restrictions you can put into a validator) but i guess this syntax is very prone for things like
<connect> <outlet ID="obj1">0</outlet> <outlet ID="obj2">1</outlet> </connect> how could you avoid this ? (connecting 2 outlets)
in the parsing of the XML-file only outlet tags get connected to inlet tags? of course it could also be something like this: <connect from="obj1" outlet="0" to="obj2" inlet="1"/> But in this case it's more difficult to connect one outlet to multiple inlets. e.g.: <connect> <outlet ID="obj1">0</outlet> <inlet ID="obj2">1</inlet> <inlet ID="obj5">0</inlet> </connect> But do we need that ?
it is not clear from your example (because it is short), but: object-identifiers ("ID") should be unique identifiers, at least within the scope of a (canvas-) tag. ID's should be able to be chosen arbitrarily, so this would be a valid patch:
I also thought in that way.
people that are writing patches in a text-editor could choose whatever ID they like (but have to make sure, that it is unique)
This way, i think, it's really much easier to write patches in a text editor.
<obj ID="foo">print</obj>
<msg ID="bar"> bang <connect n="0"> <inlet ID="foo" n="0"> <gui color="red">comment</gui> </connect> </msg>
Maybe this (and also to top down approach) should be possible additionally to the normal connect tag? But doesn't it get to complicated ?
LG Georg
Georg Holzmann wrote:
Hallo!
okay, maybe it's clearer to use a own tag for all the gui properties. So we can also easy expand these GUI-descriptions (e.g. for IEM-GUIs etc.).
yes that was the idea; and probably we will have more elaborate gui-features for normal objects in the future too. (just imaging how good a resizable [matrix~ 24 24] would be...)
in the parsing of the XML-file only outlet tags get connected to inlet tags? of course it could also be something like this:
<connect from="obj1" outlet="0" to="obj2" inlet="1"/> But in this case it's more difficult to connect one outlet to multiple inlets. e.g.: <connect> <outlet ID="obj1">0</outlet> <inlet ID="obj2">1</inlet> <inlet ID="obj5">0</inlet> </connect> But do we need that ?
actually it is not a bad idea, but... (see below)
it is not clear from your example (because it is short), but: object-identifiers ("ID") should be unique identifiers, at least within the scope of a (canvas-) tag. ID's should be able to be chosen arbitrarily, so this would be a valid patch:
I also thought in that way.
i know, but it seemed to be not that clear
<obj ID="foo">print</obj>
<msg ID="bar"> bang <connect n="0"> <inlet ID="foo" n="0"> <gui color="red">comment</gui> </connect> </msg>
Maybe this (and also to top down approach) should be possible additionally to the normal connect tag? But doesn't it get to complicated ?
ha! now (after thinking and reading your mail) i know what is wrong with the top-down approach: it encourages to connect one outlet to multiple inlets, which is, in most cases, the big bag of bugs.
so: 1) top-down is bad because it is bug-prone 2) a singular <connect> tag is bad, because a connection cannot exist without the object it connects, which would not be reflected by standalone <connect> tags. i think that the current implementation of standalone #connect-lines is just because of the flat structure of the pd-fileformat. if we go for a hierarchic model (like XML) this could be handled better. 3) bottom-up is good, because it highlights the multiplexion that is going to happen if multiple outlets are connected to one inlets. with signal-objects it reinforces the fact, that signals are being added within the inlet~.
i do not think that this is too complicated:
<nbx ID="nbx1"/> <obj ID="obj1">print <connect> <from ID="nbx1"/> </connect> </obj>
is the very simplest case where we assume the "default" in/outlet to be connected.
i don't like the one-liner like <connect from="obj1" outlet="0" to="obj2" inlet="1"/> although the naming of arguments is of course far better than my "outlet" and "n". so: <connect inlet="3"> <from ID="obj1" outlet="1"> <from ID="obj2" outlet="0"> </connect> looks somewhat ok to me (although i am not sure whether it is bad style to have an "ID"-argument that is a reference rather than the id of the connection.
and this reminds me, that probably connections really should have an id, so you could e.g. delete them directly (like "dyn")
mfg.a.dr IOhannes
hi all,
I find it hard to give up the basic Pd principle that everything may be controlled with messages. I wonder, if there is any real technical reason for abandoning message-based handling of object state (including visual properties, IDs, whatever), apart from the shortcomings of the current Pd type system -- mainly, the lack of a string type?
Krzysztof
Johannes M Zmoelnig wrote: ...
i do not think that this is too complicated:
Krzysztof Czaja wrote:
hi all,
I find it hard to give up the basic Pd principle that everything may be controlled with messages. I wonder, if there is any real technical reason for abandoning message-based handling of object
i guess there is no technical reason. you are right, that the simplicity of pd's internal format is one of its strengths which need not unneccessarrilly be abandoned.
state (including visual properties, IDs, whatever), apart from the
but i think it is important that we separate between visual properties and functional behaviour. for an example, the iemguis store a lot of gui-information in a long long list of arguments. i think this is bad style, but it is not thomas' fault as this is the way how it works: one object is entirely representated by one message. the problem with this is that you cannot expand it (just have a look at the evolution of the arguments of the iemgui's)
mfg.a.dsr IOhannes
but i think it is important that we separate between visual properties and functional behaviour. for an example, the iemguis store a lot of gui-information in a long long list of arguments. i think this is bad style, but it is not thomas' fault as this is the way how it works: one object is entirely representated by one message. the problem with this is that you cannot expand it (just have a look at the evolution of the arguments of the iemgui's)
I'm personally using flext attributes with great success. It uses the Max/Jitter style of @arguments, which allows easy structuring of creation arguments. Flext also has a built-in editor for that (context menu "properties")
best greetings, Thomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As more people ask for features in popup the more a property dialog looks best... It seems too early to worry about this for me since all I really want is a nice stable API for gui externs in PD that include property dialogs.
Miller, do you have any interest/estimate on this?
Oh and while I'm on the topic, is there a function in the PD API to remove special characters from strings that have special PD meaning (; $ \ etc..) and pass a clean string of atoms on..? (right now you can type "; pd-array clear" in the "entry" box and it will send the message to the pd-array receive. Cute for some things, a pain for others...
B.
Thomas Grill wrote: |>but i think it is important that we separate between visual properties |>and functional behaviour. |>for an example, the iemguis store a lot of gui-information in a long |>long list of arguments. i think this is bad style, but it is not thomas' |>fault as this is the way how it works: one object is entirely |>representated by one message. |>the problem with this is that you cannot expand it (just have a look at |>the evolution of the arguments of the iemgui's) | | | I'm personally using flext attributes with great success. It uses the | Max/Jitter style of @arguments, which allows easy structuring of creation | arguments. Flext also has a built-in editor for that (context menu | "properties") | | best greetings, | Thomas | | | _______________________________________________ | PD-dev mailing list | PD-dev@iem.at | http://iem.at/cgi-bin/mailman/listinfo/pd-dev |
On Dec 14, 2004, at 6:53 AM, Johannes M Zmoelnig wrote:
Krzysztof Czaja wrote:
hi all, I find it hard to give up the basic Pd principle that everything may be controlled with messages. I wonder, if there is any real technical reason for abandoning message-based handling of object
i guess there is no technical reason. you are right, that the simplicity of pd's internal format is one of its strengths which need not unneccessarrilly be abandoned.
state (including visual properties, IDs, whatever), apart from the
but i think it is important that we separate between visual properties and functional behaviour. for an example, the iemguis store a lot of gui-information in a long long list of arguments. i think this is bad style, but it is not thomas' fault as this is the way how it works: one object is entirely representated by one message. the problem with this is that you cannot expand it (just have a look at the evolution of the arguments of the iemgui's)
There was some discussion of trying to implement iemguis and unauthorized guis using data structures. Frank has already implemented sliders and a [grid]-style object. It seems to me that this would be the ultimate way to handle this in a native Pd way.
.hc
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
There was some discussion of trying to implement iemguis and unauthorized guis using data structures. Frank has already implemented sliders and a [grid]-style object. It seems to me that this would be the ultimate way to handle this in a native Pd way.
i agree this would be a good thing, that is the ability to map the pure data structures to things like blt::vector's or named tcl arrays, for those not content with using mere shapes on a canvas! and then define the gui which 'houses' the mapped data in simple tk, something similar to the miXed/ '.wid' format but eliminating the need to think/code add|remove|update|sync each and every...
oh and to keep this thread on topic, do you find:
<list>this list<list>inside<list>a list</list></list></list>
to be more human readable than:
this list {inside {a list}}
?
c
Ok this is wetting my appetite.
I asked a while back about anyone having an example of datastructures being used for something other can canvas drawing. No one responded.
So now seems like a good time to ask again.
Are there examples of pd datastructures being used for something other than canvas drawing!? Please send me!
Things I'm working on now for pixelTANGO: * state-saving with memento, except the OSC names are specified dynamically
* dynamic naming of abstractions (instance counting within a class, all in PD land)
* dynamic routing.. I'm working on an abstraction call dir2abstractionArray that takes a path glob pattern and uses that to generate an array of each abstraction in the directory. These abstractions have two inlets and two outlets that can be used for anything. Anything going into the two inputs on the dir2abstractionArray get routed to the abstraction selected by its index value, and anything going through the abstractions outlets (when the index value matches) gets routed to the dir2abstractionArray outlets. I'm using this to switch between various pix_ effects in gem, where each abstraction fx/edge has a standard interface to the parent patch. The point is that the user can drag and drop a bunch of abstractions (from friends for example) and boom, they show up in a popup list automatically.
* OSC name registration so that the dynamically named abstractions dump all thier data in a pool and there is a cental repository of all the OSC names in a patch that is generated on loading the patch. I'm hoping to be able to automatically associate MIDI controlers to each of these OSC names...
Perhaps data-structures could make some of this stuff a little less messy.
B/
zf wrote:
There was some discussion of trying to implement iemguis and unauthorized guis using data structures. Frank has already implemented sliders and a [grid]-style object. It seems to me that this would be the ultimate way to handle this in a native Pd way.
i agree this would be a good thing, that is the ability to map the pure data structures to things like blt::vector's or named tcl arrays, for those not content with using mere shapes on a canvas! and then define the gui which 'houses' the mapped data in simple tk, something similar to the miXed/ '.wid' format but eliminating the need to think/code add|remove|update|sync each and every...
oh and to keep this thread on topic, do you find:
<list>this list<list>inside<list>a list</list></list></list>
to be more human readable than:
this list {inside {a list}}
?
c
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Krzysztof Czaja wrote:
hi all,
I find it hard to give up the basic Pd principle that everything may be controlled with messages. I wonder, if there is any real technical reason for abandoning message-based handling of object state (including visual properties, IDs, whatever)
As I understand it, the XML format is only for storing patchers in a way that will ensure that they can be reliably reproduced on any supported platform. Nobody is talking about changing messages.
Martin
, apart from the shortcomings of the current Pd type system -- mainly, the lack of a string type?
Krzysztof
Johannes M Zmoelnig wrote: ...
i do not think that this is too complicated:
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Tue, 14 Dec 2004, Martin Peach wrote:
As I understand it, the XML format is only for storing patchers in a way that will ensure that they can be reliably reproduced on any supported platform. Nobody is talking about changing messages.
What counts as a platform here and what's the problem with decoding the .pd format on any platform from any programming language ?
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Mathieu Bouchard wrote:
What counts as a platform here and what's the problem with decoding the
there is no problem with the crossplatformity of pd-patches (as we are constantly proving)
.pd format on any platform from any programming language ?
XML would make multi-language ("real" languages, not programming langs) support better (e.g. using french accents or cyrillic letters could be handled by different encodings, which is not supported by the pd-format (and i don't feel that adding an "encoding" flag to the #canvas would be anything else but a hack)
mfg.a.sr IOhannes
hi Johannes,
#X encoding... or #X prop encoding...
What is still missing, is a standard way of setting state of patchable objects during their creation. There are some examples, like #A for arrays, #C for cyclone containers, but we need a standard.
Editing creation code in xml is fine as a secondary interface, just as are property dialogs, etc.
Krzysztof
IOhannes m zmoelnig wrote: ...
(and i don't feel that adding an "encoding" flag to the #canvas would be anything else but a hack)
Mathieu Bouchard wrote:
On Tue, 14 Dec 2004, Martin Peach wrote:
As I understand it, the XML format is only for storing patchers in a way that will ensure that they can be reliably reproduced on any supported platform. Nobody is talking about changing messages.
What counts as a platform here and what's the problem with decoding the .pd format on any platform from any programming language ?
In the usual sense, currently pd seems to work on linux, MacOSX, Windows... The only problem I have with the pd format is that if you introduce new features into it, it's not backwards-compatible. A robust XML parser will ignore tags it doesn't handle.
Martin
On Tue, 14 Dec 2004, Krzysztof Czaja wrote:
I find it hard to give up the basic Pd principle that everything may be controlled with messages. I wonder, if there is any real technical reason for abandoning message-based handling of object state (including visual properties, IDs, whatever), apart from the shortcomings of the current Pd type system -- mainly, the lack of a string type?
Exactly. This is what I should have said when I asked the question "Why?".
Here's an idea:
* the Pd format is two fingers away from being a subset of the Tcl syntax: they are compatible in their handling of spaces and semicolons. The dollar signs are also somewhat similar.
* The "two fingers away" is that the handful of special characters of Tcl are mostly not special in Pd, or else are saved/reloaded in broken ways (e.g. backslashes).
* The special characters of Tcl could bring a lot more features to Pd, such as: {} for nested lists $ with more options \ escaping, saving non-ascii chars "" string [] (not sure how this would map to Pd)
* Using concepts from Tcl is a kind of reuse from a language that Pd already has some syntaxical affinity with. (Whether Tcl inspired Pd or SH inspired Pd or whatever else is besides the point; the point is that right now Pd looks somewhat like Tcl.)
* Most of those features would become useable all over Pd, including [netsend]/[netreceive] and all patchers. This is the killer feature of this proposal. AFAIK, the XML side of things doesn't do anything about it.
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Mathieu Bouchard wrote:
On Tue, 14 Dec 2004, Krzysztof Czaja wrote:
I find it hard to give up the basic Pd principle that everything may be controlled with messages. I wonder, if there is any real technical reason for abandoning message-based handling of object state (including visual properties, IDs, whatever), apart from the shortcomings of the current Pd type system -- mainly, the lack of a string type?
Exactly. This is what I should have said when I asked the question "Why?".
i think we are not talking about replacing the pd-format with an XML-format (we can talk about this later)
but i think that there is a need for a human-readable file-format (which could be an addition, either built-in or as an external)
mfg.asd.r IOhannes
Hallo!
<nbx ID="nbx1"/> <obj ID="obj1">print <connect> <from ID="nbx1"/> </connect> </obj>
But in this bottom-up approach the number box of this example must be created before the print ! (as we spoke about yeterday) So you can't simple put the objects on the empty canvas and then connect them (of course you can do that too, but i think this is more complicated ?)
<connect inlet="3"> <from ID="obj1" outlet="1"> <from ID="obj2" outlet="0"> </connect> looks somewhat ok to me (although i am not sure whether it is bad style to have an "ID"-argument that is a reference rather than the id of the connection.
what about name ? : <connect inlet="3"> <from name="obj1" outlet="1"> <from name="obj2" outlet="0"> </connect>
and this reminds me, that probably connections really should have an id, so you could e.g. delete them directly (like "dyn")
like this: <nbx ID="nbx1"/> <obj ID="obj1">print <connect ID="blabla" inlet="0"> <from ID="nbx1" outlet="0"/> </connect> </obj>
but which advantages has this approach? You could also go to the object and delete the connection (and in the bottom-up style the object would be the one under the connection). And if you give labels to the connections you also have to remeber these if you are writing a patch in an editor (so that you don't use one label multiple times).
LG Georg
Georg Holzmann wrote:
and this reminds me, that probably connections really should have an id, so you could e.g. delete them directly (like "dyn")
like this:
<nbx ID="nbx1"/> <obj ID="obj1">print <connect ID="blabla" inlet="0"> <from ID="nbx1" outlet="0"/> </connect> </obj>
Maybe it would be better to separate the connections and the objects. To delete an object would also entail deleting any connections referencing that object, which would not affect the remaining objects. It simplifies parsing the file if the objects are listed first, then the connections:
<obj ID="obj1">print </obj> <obj ID="obj2">numberbox </obj> ... <connect ID="connect1"> <from ID="obj1" outlet="0"/> <to ID="obj2" outlet="0"/> </connect> ...
Martin
Georg Holzmann wrote:
Hallo!
<nbx ID="nbx1"/> <obj ID="obj1">print <connect> <from ID="nbx1"/> </connect> </obj>
But in this bottom-up approach the number box of this example must be created before the print ! (as we spoke about yeterday) So you can't simple put the objects on the empty canvas and then connect them (of course you can do that too, but i think this is more complicated ?)
i meant, that you first should parse the whole XML-domtree and afterwards create the objects and connect them (when you already know what is there)
what about name ? :
<connect inlet="3"> <from name="obj1" outlet="1"> <from name="obj2" outlet="0"> </connect>
well, i really don't care...
like this:
<nbx ID="nbx1"/> <obj ID="obj1">print <connect ID="blabla" inlet="0"> <from ID="nbx1" outlet="0"/> </connect> </obj>
but which advantages has this approach? You could also go to the object and delete the connection (and in the bottom-up style the object would be the one under the connection). And if you give labels to the connections you also have to remeber these if you are writing a patch in an editor (so that you don't use one label multiple times).
hmm yes; probably make the connect-ID optional (so you _could_ name it and delete it as such or choose to delete it based on the object)
the advantages i really don't know, it was just an idea, as i found the dyn-approach quite good (as far as i remember it). but probably XML-files wouldn't be the way you would go when doing dynamic patching - otoh why not ? you would then need to have atomic transactions, which isn't that bad either.
mfg.asd.r IOhannes
-
B. Bogart -
Georg Holzmann -
Hans-Christoph Steiner -
Ian Smith-Heisters -
IOhannes m zmoelnig -
Johannes M Zmoelnig
-
Krzysztof Czaja -
Martin Peach -
Mathieu Bouchard -
Thomas Grill -
zf