Through trial and error I've managed to reach what I thought was an understanding of Pd file format. However, on deeper analysis I keep discovering I'm wrong, in fact the Pd file structure and the syntax of the statements is not what I thought (which explains many previous programming errors).
I think it's been asked before and received no satisfactory answer, so once again - Where is the complete file format and syntactic definitions of the Pd file documented (not by reading through the source of the parser)?
Would someone care to go through and explain in a simple tutorial how Pd constructs its netlist and what are the meanings of the parameters to each of these statements
#X msg 125 100 bang;
An easy one, a message containing [bang( at coordinates 125 100, right?
#X obj 144 128 s $1-zero;
And again, an object of class "send" at coords 144,128 with name $1-zero.
#X array $1-THREE 6485 float 0;
Maybe an easy one, we create an array called $1-THREE of size 6485 of type float. And an array doesn't need coordinates because a graph has the coordinates not the array. But what is that 0 at the end?
#N canvas 0 22 450 300 graph1 0; #X restore 235 308 graph1;
What is the real purpose of restore? What are these parameters? How does it relate to the canvas?
What the hell is coords? Why?
#X coords 0 1.02 6484 -1.02 200 130 1;
#X connect 60 0 62 0;
Can anyone thoroughly explain connections and how their ordering is important? It's an ordered adjacency matrix?
I think this would be very helpful for everyone to have properly documented somewhere.
Cheers,
Andy
#X array $1-THREE 6485 float 0;
as i just found out, you need a backslash in front of $ args. eg.. /$1-THREE
no idea what the float 0 means though.
Hi,
Andy Farnell a écrit :
#N canvas 0 22 450 300 graph1 0; #X restore 235 308 graph1;
What is the real purpose of restore? What are these parameters? How does it relate to the canvas?
What the hell is coords? Why?
#X coords 0 1.02 6484 -1.02 200 130 1;
This is the parameters in canvas properties windows, you can also set those parameters with the message to the patch "donecanvasdialog"
Can anyone thoroughly explain connections and how their ordering is important? It's an ordered adjacency matrix?
I've attached a patch that illustrate how it could be important. Each time it receive a different MIDI controller datum, the patch creates two objects and connects them, we can find out what object have been created with a counter because they have been numbered in order of apparition.
There also is a trick in the patch with "makefilename %c" for inserting "" into created object (see into pd $1-float), so with the $1 argument the dynamically created object keeps the dollar sign instead of being replaced by the variable value.
I think this would be very helpful for everyone to have properly documented somewhere.
A dynamic patching tutorial would be appreciated as well.
Cheers,
Andy
Steffen Juul a écrit :
On 16/10/2007, at 12.40, Patrice Colet wrote:
I think this would be very helpful for everyone to have properly documented somewhere.
A dynamic patching tutorial would be appreciated as well.
There is something in CVSROOT/doc/additional/pd-msg/
That's nice, but it doesn't work, nothing is happening when we click on a message, in those documentation patches the send object and the patch haven't got the same name, for having this working we have to edit the send object.
Patrice Colet a écrit :
Steffen Juul a écrit :
On 16/10/2007, at 12.40, Patrice Colet wrote:
I think this would be very helpful for everyone to have properly documented somewhere.
A dynamic patching tutorial would be appreciated as well.
There is something in CVSROOT/doc/additional/pd-msg/
That's nice, but it doesn't work, nothing is happening when we click on a message, in those documentation patches the send object and the patch haven't got the same name, for having this working we have to edit the send object.
Why the hell do you want to deprecate namecanvas?!
On Tue, 2007-10-16 at 15:28 +0200, Patrice Colet wrote:
Patrice Colet a écrit :
Steffen Juul a écrit :
On 16/10/2007, at 12.40, Patrice Colet wrote:
I think this would be very helpful for everyone to have properly documented somewhere.
A dynamic patching tutorial would be appreciated as well.
There is something in CVSROOT/doc/additional/pd-msg/
That's nice, but it doesn't work, nothing is happening when we click on a message, in those documentation patches the send object and the patch haven't got the same name, for having this working we have to edit the send object.
Why the hell do you want to deprecate namecanvas?!
i think, there is a consent in the pd-community, that [namecanvas] shouldn't be considered to be deprecated. you'll find a lot of post in the archive about this. i believe, it is just a matter of miller removing that sentence from the help-file.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
i think, there is a consent in the pd-community, that [namecanvas] shouldn't be considered to be deprecated. you'll find a lot of post in the archive about this. i believe, it is just a matter of miller removing that sentence from the help-file.
I think, one of the problems of [namecanvas] is that it's an object, and thus it can be deleted by a message. One suggested way out was to instead make namecanvas an actual property of the canvas, that is set through the props menu.
Ciao
Frank Barknecht _ ______footils.org__
Hi,
Frank Barknecht a écrit :
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
i think, there is a consent in the pd-community, that [namecanvas] shouldn't be considered to be deprecated. you'll find a lot of post in the archive about this. i believe, it is just a matter of miller removing that sentence from the help-file.
First I sorry to bring back this discussion to the list, that might not appear anymore if a definitive solution is found, and applied.
I think, one of the problems of [namecanvas] is that it's an object, and thus it can be deleted by a message. One suggested way out was to instead make namecanvas an actual property of the canvas, that is set through the props menu.
Ciao
Oh yes, that clearly shows the problem involved by this object, if it's deleted, I suppose (but didn't test) that the graph would take back it's original name and then messages sent through [namecanvas] argument sender won't come anymore to the targeted graph.
The proposed solution seems very good and AFAIU it would appear like in this canvas pattern:
#X coords 0 1 99 -1 200 140 1 /$0-name-of-the-graph;
Unfortunately I've no clue how to do it myself yet, and hope this is not "talk for nothing".
On Wed, 17 Oct 2007, Patrice Colet wrote:
The proposed solution seems very good and AFAIU it would appear like in this canvas pattern: #X coords 0 1 99 -1 200 140 1 /$0-name-of-the-graph; Unfortunately I've no clue how to do it myself yet, and hope this is not "talk for nothing".
It's not a slash, it's a backslash, just as in Bash and Tcl.
non-backslashed $ should never appear in a patch file.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Wed, 17 Oct 2007, Frank Barknecht wrote:
I think, one of the problems of [namecanvas] is that it's an object, and thus it can be deleted by a message. One suggested way out was to instead make namecanvas an actual property of the canvas, that is set through the props menu.
tell me what should happen to [import] and [block~]...
and if they have to be handled differently: why.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 17 Oct 2007, Frank Barknecht wrote:
I think, one of the problems of [namecanvas] is that it's an object, and thus it can be deleted by a message. One suggested way out was to instead make namecanvas an actual property of the canvas, that is set through the props menu.
tell me what should happen to [import] and [block~]...
and if they have to be handled differently: why.
As I see it, the only purpose of [namecanvas] is to allow sending messages to an instance of an abstraction and generally these messages involve some kind of dynamic editing. Building a network of objects on a canvas often is easier to make when starting from scratch with an empty canvas (because of connection numbering etc.). But you cannot clear the canvas when using [namecanvas]!
This restriction leads to really ugly workarounds. Just compare the old version of nqpoly4 with the version, where I removed the [namecanvas] (which was unnecessary here anyway) and used a subpatch instead. If "namecanvas" was a property of the canvas, one could patch abstraction instances dynamically just like subpatches.
Ciao
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
As I see it, the only purpose of [namecanvas] is to allow sending messages to an instance of an abstraction and generally these messages involve some kind of dynamic editing. Building a network of objects on a canvas often is easier to make when starting from scratch with an empty canvas (because of connection numbering etc.). But you cannot clear the canvas when using [namecanvas]!
Actually it occured to me that this is a silly argument, which I could only bring up, because I'm living proof that creating non-trivial Pd patches for 6 years is possible without ever using namecanvas once.
It's silly, because of course one would normally not want to clear the main canvas of an abstraction altogether as that would also clear the logic to fill the canvas again, and this logic generally would be in the abstraction itself.
This restriction leads to really ugly workarounds.
Second silly argument: dynamically patching an abstracion instance would still be ugly even when namcanvas was a property, as you'd still need to keep track of how many objects your logic (see above) contains and you would not be allowed to change it.
Ciao
Frank Barknecht _ ______footils.org__
Actually it occured to me that this is a silly argument, which I could only bring up, because I'm living proof that creating non-trivial Pd patches for 6 years is possible without ever using namecanvas once.
One could also create non-trivial Pd patches for 6 years and not use data structures once (or even DSP objects), this does not mean they are useless : ).
It's silly, because of course one would normally not want to clear the
main canvas of an abstraction altogether as that would also clear the logic to fill the canvas again, and this logic generally would be in the abstraction itself.
This restriction leads to really ugly workarounds.
Second silly argument: dynamically patching an abstracion instance would still be ugly even when namcanvas was a property, as you'd still need to keep track of how many objects your logic (see above) contains and you would not be allowed to change it.
Ugly it may be but we've established that there are certain things that are impossible without namecanvas, such as my most recent [msend]/[mreceive] with variable inlets/outlets, or Chris McCormick's patches that do dynamic GOP.
Not to mention, look at this! http://artengine.ca/desiredata/gallery/numbered_objects.gif
That would make it a lot less painful. Even better would be allowing us to assign identifiers to objects or groups of objects for stable manipulation... but the above is a huge help.
So, I am very much in support of moving namecanvas to the canvas properties window, and I hope we can agree that it is an essential feature (rereading, maybe that is what you were trying to say after all, but I don't mind campaigning for it anyways : ) ).
Cheers Luke proyekto.net
Mathieu Bouchard wrote:
On Wed, 17 Oct 2007, Frank Barknecht wrote:
I think, one of the problems of [namecanvas] is that it's an object, and thus it can be deleted by a message. One suggested way out was to instead make namecanvas an actual property of the canvas, that is set through the props menu.
tell me what should happen to [import] and [block~]...
they should stay.
and if they have to be handled differently: why.
[import] is an external; allowing externals to add new properties persistently will most likely blow the current pd fileformat.
imho, [block~] should actually be a property. however, this means that we do need a way to communicate with the patch directly, because [block~] has an inlet that is used...
personally i would love to have a (non-deletable) inlet somewhere in the patch (at the bottom?) that can be used to send messages to the canvas instead of binding it to a receiver name. but then: how does this fix the problem of delete all?
fmsr.d IOhanes
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
#X array $1-THREE 6485 float 0;
Maybe an easy one, we create an array called $1-THREE of size 6485 of type float. And an array doesn't need coordinates because a graph has the coordinates not the array. But what is that 0 at the end?
It's a flag specifiying the array's properties: "save contents", "draw as points" etc. I don't know how exactly this is built, use the source, Luke. ;)
#N canvas 0 22 450 300 graph1 0; #X restore 235 308 graph1;
What is the real purpose of restore? What are these parameters? How does it relate to the canvas?
The pair (canvas, restore) is like a bracket. Usually this is used to specify start and end of a subpatches. It also resets the object counter temporarily: "connect" inside a subpatch starts counting objetcs at 0 again. The object counter of the parent is restored after the end of the subpatch. See attached example "canvas-restore.pd" It also contains things like "GOP enabled?" etc.
Your example is a pure graph however, not a subpatch. Pure graphs are used to hold arrays, and they have a bit different parameters. See below. I think the parameters to "restore" hold the position of the subcanvas in the parent.
What the hell is coords? Why?
#X coords 0 1.02 6484 -1.02 200 130 1;
Coordinates (size etc.) of the subpatch or graph. Check the "Properties" of the graph/subpatch. and attached example "graphs-and-arrays.pd"
Ciao
Frank Barknecht _ ______footils.org__
On 16/10/2007, at 22.51, Andy Farnell wrote:
Where is the complete file format and syntactic definitions of the Pd file documented (not by reading through the source of the parser)?
Though it might not be up to date i think there has been made an
attempt in CVSROOT/doc/additional/pd-fileformat.html
A quick search of puredata.org turns up:
http://puredata.info/docs/developer/fileformat
There's lots of good stuff there! :D
.hc
On Oct 16, 2007, at 4:51 PM, Andy Farnell wrote:
Through trial and error I've managed to reach what I thought was an understanding of Pd file format. However, on deeper analysis I keep discovering I'm wrong, in fact the Pd file structure and the syntax of the statements is not what I thought (which explains many previous programming errors).
I think it's been asked before and received no satisfactory answer, so once again - Where is the complete file format and syntactic definitions of the Pd file documented (not by reading through the source of the parser)?
Would someone care to go through and explain in a simple tutorial how Pd constructs its netlist and what are the meanings of the parameters to each of these statements
#X msg 125 100 bang;
An easy one, a message containing [bang( at coordinates 125 100,
right?#X obj 144 128 s $1-zero;
And again, an object of class "send" at coords 144,128 with name $1- zero.
#X array $1-THREE 6485 float 0;
Maybe an easy one, we create an array called $1-THREE of size 6485 of type float. And an array doesn't need coordinates because a
graph has the coordinates not the array. But what is that 0 at the end?#N canvas 0 22 450 300 graph1 0; #X restore 235 308 graph1;
What is the real purpose of restore? What are these parameters? How
does it relate to the canvas?What the hell is coords? Why?
#X coords 0 1.02 6484 -1.02 200 130 1;
#X connect 60 0 62 0;
Can anyone thoroughly explain connections and how their ordering is important? It's an ordered adjacency matrix?
I think this would be very helpful for everyone to have properly documented somewhere.
Cheers,
Andy
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
FYI: thats also the first hit in google for "puredata file format"...
and as it is a wiki page, please do modify it if you find something that doesnt match, as i may also need it in the "near" future ;)
.andre
On Tue, 2007-10-16 at 19:09 -0400, Hans-Christoph Steiner wrote:
A quick search of puredata.org turns up:
http://puredata.info/docs/developer/fileformat
There's lots of good stuff there! :D
.hc
On Oct 16, 2007, at 4:51 PM, Andy Farnell wrote:
Through trial and error I've managed to reach what I thought was an understanding of Pd file format. However, on deeper analysis I keep discovering I'm wrong, in fact the Pd file structure and the syntax of the statements is not what I thought (which explains many previous programming errors).
I think it's been asked before and received no satisfactory answer, so once again - Where is the complete file format and syntactic definitions of the Pd file documented (not by reading through the source of the parser)?
Would someone care to go through and explain in a simple tutorial how Pd constructs its netlist and what are the meanings of the parameters to each of these statements
#X msg 125 100 bang;
An easy one, a message containing [bang( at coordinates 125 100,
right?#X obj 144 128 s $1-zero;
And again, an object of class "send" at coords 144,128 with name $1- zero.
#X array $1-THREE 6485 float 0;
Maybe an easy one, we create an array called $1-THREE of size 6485 of type float. And an array doesn't need coordinates because a
graph has the coordinates not the array. But what is that 0 at the end?#N canvas 0 22 450 300 graph1 0; #X restore 235 308 graph1;
What is the real purpose of restore? What are these parameters? How
does it relate to the canvas?What the hell is coords? Why?
#X coords 0 1.02 6484 -1.02 200 130 1;
#X connect 60 0 62 0;
Can anyone thoroughly explain connections and how their ordering is important? It's an ordered adjacency matrix?
I think this would be very helpful for everyone to have properly documented somewhere.
Cheers,
Andy
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Exactly what I was looking for. Bookmarked. Thankyou Hans and everyone for your suggestions.
To put it in context... I was attempting to solve/answer an occasionally recurring problem for someone.. "My Pd file is corrupt and all the objects have vanished"
I solved this before by trial and error, matching up canvas statements with restore statements (It does indeed work as I thought, pretty much).
a.
On Tue, 16 Oct 2007 19:09:09 -0400 Hans-Christoph Steiner hans@eds.org wrote:
A quick search of puredata.org turns up:
http://puredata.info/docs/developer/fileformat
There's lots of good stuff there! :D
.hc
On Oct 16, 2007, at 4:51 PM, Andy Farnell wrote:
Through trial and error I've managed to reach what I thought was an understanding of Pd file format. However, on deeper analysis I keep discovering I'm wrong, in fact the Pd file structure and the syntax of the statements is not what I thought (which explains many previous programming errors).
I think it's been asked before and received no satisfactory answer, so once again - Where is the complete file format and syntactic definitions of the Pd file documented (not by reading through the source of the parser)?
Would someone care to go through and explain in a simple tutorial how Pd constructs its netlist and what are the meanings of the parameters to each of these statements
#X msg 125 100 bang;
An easy one, a message containing [bang( at coordinates 125 100,
right?#X obj 144 128 s $1-zero;
And again, an object of class "send" at coords 144,128 with name $1- zero.
#X array $1-THREE 6485 float 0;
Maybe an easy one, we create an array called $1-THREE of size 6485 of type float. And an array doesn't need coordinates because a
graph has the coordinates not the array. But what is that 0 at the end?#N canvas 0 22 450 300 graph1 0; #X restore 235 308 graph1;
What is the real purpose of restore? What are these parameters? How
does it relate to the canvas?What the hell is coords? Why?
#X coords 0 1.02 6484 -1.02 200 130 1;
#X connect 60 0 62 0;
Can anyone thoroughly explain connections and how their ordering is important? It's an ordered adjacency matrix?
I think this would be very helpful for everyone to have properly documented somewhere.
Cheers,
Andy
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
-
Andre Schmidt -
Andy Farnell -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
Luke Iannini (pd) -
Mathieu Bouchard -
Patrice Colet -
Roman Haefeli -
Steffen Juul