Dear list.
I'm creating some documentation about how PD can manage self-construction of patch. (a patch can create an other one... )
My work is based on *pdscript* by Guenter (thanks) and g_canvas.c + u_main.tk.
It's currently only a directory to add in /doc/7.stuff/ with 3 patchs to show how to create things from pd. + *pdscript* + a tcl that create a sub-patch in PD.
To acheive this work i'll need some more informations about how we can use pd via a socket.
I curently don't kown :
where can i find more information about it ?
by the way, i'm very interested about how pd work. where can i find documentaion about it ? what are the most importants files in the code ?
thanks.
Damien HENRY.
Whoops, thought this was an obvious one but can't find anything in the doc: can I play standard midi files, and if so, how?
Michael
Michael Edwards Tel: Office: +43 (0)662 6198-5125 Universitaet Mozarteum Home: +43 (0)662 844462 Fuerbergstrasse 18-20 Mobile: +43 (0)699 11 686 441 A-5020 Salzburg Email: mailto:m@michael-edwards.org Austria Web: http://www.michael-edwards.org ________________________________________________________________________
I worked on a midi-to-qlist converter app that sort of worked. I never got the tempo to convert very well though. I can send you the source if you want.
On Sun, 15 Jul 2001, HENRY Damien wrote:
<snip> > To acheive this work i'll need some more informations about how we can use pd > via a socket. > > I curently don't kown : > * how removing an (obj/msg/etc..) in a patch. > * how unconnecting (obj/msg/etc..) > * how showing or hiding a sub patch > * what it's possible to do and what's is not... > > where can i find more information about it ? > > by the way, i'm very interested about how pd work. > where can i find documentaion about it ? > what are the most importants files in the code ? >
I don't think there is too much documentation about the inner workings of the pd, it's all in the code though.
The messages pdscript uses are either in m_glob.c or in g_canvas.c.
AFAIK there is no delete message, although there has been some talk about it some months ago.
You can fake it by using different messages to the canvas, like "motion" to position the mouse, select, and cut.
If you are able to remember the positions of your objects that might by ok. There is no way to store references to the objects, but coding references in position information is ok as long as there are no overlaps.
A raw list of important source files: s_inter.c, s_main.c (s_* could stand for system ..)
the m_* files implement the object structures, and messageing. (m_sched.c where m_scheduler is the main loop of pd, m_glob, .. well, almost everything is important because pd builds up on these objects)
d_* for "DSP", I think, where d_ugen.c is the important part,
g_ might stand for graph, everything that has to do with graphical objects ..
x_ is, well, other objects that do something, not dsp related
Hope that helps, (and I hope it is correct :) ).
Guenter
Thanks forum::für::umläute ; guenter & Johannes for your reply.
thoses 3 lines in pdscript are still not very clear for me : pd filename new ./; #N canvas; #X pop 1;
is filename something like "new" what are #N & #X ? pop is used instead of vis ? this is all mystery to me.
I'll post the updated documentation soon.
Damien HENRY
Le Lundi 16 Juillet 2001 06:37, guenter geiger a écrit :
On Sun, 15 Jul 2001, HENRY Damien wrote:
<snip>
To acheive this work i'll need some more informations about how we can use pd via a socket.
I curently don't kown :
- how removing an (obj/msg/etc..) in a patch.
- how unconnecting (obj/msg/etc..)
- how showing or hiding a sub patch
- what it's possible to do and what's is not...
where can i find more information about it ?
by the way, i'm very interested about how pd work. where can i find documentaion about it ? what are the most importants files in the code ?
I don't think there is too much documentation about the inner workings of the pd, it's all in the code though.
The messages pdscript uses are either in m_glob.c or in g_canvas.c.
AFAIK there is no delete message, although there has been some talk about it some months ago.
You can fake it by using different messages to the canvas, like "motion" to position the mouse, select, and cut.
If you are able to remember the positions of your objects that might by ok. There is no way to store references to the objects, but coding references in position information is ok as long as there are no overlaps.
A raw list of important source files: s_inter.c, s_main.c (s_* could stand for system ..)
the m_* files implement the object structures, and messageing. (m_sched.c where m_scheduler is the main loop of pd, m_glob, .. well, almost everything is important because pd builds up on these objects)
d_* for "DSP", I think, where d_ugen.c is the important part,
g_ might stand for graph, everything that has to do with graphical objects ..
x_ is, well, other objects that do something, not dsp related
Hope that helps, (and I hope it is correct :) ).
Guenter
hi
don't know whether my first mail managed to get sent (we had problems with our user-server)
Dear list.
I'm creating some documentation about how PD can manage self-construction of patch. (a patch can create an other one... )
fine
I curently don't kown :
- how removing an (obj/msg/etc..) in a patch.
- how unconnecting (obj/msg/etc..)
- how showing or hiding a sub patch
- what it's possible to do and what's is not...
as far as i know, there are (yet) no possibilities to remove obj/msg/connections. (i once tried to make a "remove"-function but it was buggy (crashed after a few thousand instantiations/deletions but more unfortunately, i have lost the code)
you can control a subpatch <subpatch> by sending messages to "pd-<subpatch>". to make it pop up, send it a "vis 1" message, and guess what you have to do to make it vanish ?? (hint : "vis 0")
#N canvas 266 171 450 300 10; #N canvas 205 134 600 400 my-subpatch 0; #X restore 126 205 pd my-subpatch; #X msg 31 104 ; pd-my-subpatch vis 1; #X msg 191 103 ; pd-my-subpatch vis 0; #X text 41 84 pop-up; #X text 194 85 close;
by the way (especially for miller): what is the proper way for creating controllable local subpatches ? meaning: i am having an abstraction including a subpatch, which i would like to control (for drawing scalars, automatic object generation). unfortunately i would have more of these abstractions (because they are s cute) in a meta-patch. how should i handle this ? creating a subpatch "pd $0_sub" and controlling it via the object name "pd-$0_sub" (a bit complicated to create with makefilename but possible) works only so long, as i am not saving this abstraction and reusing it in my meta-patch. (funny thing: when creating (in edit mode) a subpatch "pd $0_sub" the $0 will immediately appear replaced by its integer representation (pe: 1003) in the header-line of the subpatch-window. when saving the abstraction and using it, this replacement does not take place !) the only way would be to use the "namecanvas" object within my subpatch (call the subpatch "sub" and insert a "namecanvas $0_sub", and address it with $0_sub, which by the way, is far easier to do than to address "pd-'$0'_sub"). but as i understand all the warning messages, i am strongly discouraged to use the "namecanvas" (obsolete,...) i hope that though the "namecanvas" is obsolete, it will never be removed from pd's functionality (since it would break many of my patches)
mfg.rtz.csd IOhannes
where can i find more information about it ?
by the way, i'm very interested about how pd work. where can i find documentaion about it ? what are the most importants files in the code ?
thanks.
Damien HENRY.