I would like to start adding in all of the useful abstractions to the various Pd distros and I think we should work out a standard way of doing it. The way I see it, abstractions fall into two categories: external objects just like those written in C, C++, whatever; and, performance/tutorial/demo/etc. patches.
- for the first type (externals written in Pd): it seems to me that these should be in a directory much like "extra" which would be added to the path. I think that using externals written in Pd should be as transparent as using an external written in C/C++/etc. Perhaps these should just be put in the "extra" folder like all of the compiled objects as well.
- for the second type (performance/tutorial/demo/etc. patches): these should be in a browsable, organized layout so that anyone can look thru them all and try out various things.
Thoughts, suggestions, comments?
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On Sun, 22 Aug 2004, Hans-Christoph Steiner wrote:
- for the first type (externals written in Pd): it seems to me that
these should be in a directory much like "extra" which would be added to the path. I think that using externals written in Pd should be as transparent as using an external written in C/C++/etc. Perhaps these should just be put in the "extra" folder like all of the compiled objects as well.
IMHO the way abstractions work should be as close as possible to the way externals work. I like to think of abstractions as a kind of external that is "written in" the PureData "language".
BTW I'd like to know how to set a help file for an abstraction that is not just the abstraction itself.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Mon, 23 Aug 2004, Mathieu Bouchard wrote:
On Sun, 22 Aug 2004, Hans-Christoph Steiner wrote:
- for the first type (externals written in Pd): it seems to me that
these should be in a directory much like "extra" which would be added to the path. I think that using externals written in Pd should be as transparent as using an external written in C/C++/etc. Perhaps these should just be put in the "extra" folder like all of the compiled objects as well.
IMHO the way abstractions work should be as close as possible to the way externals work. I like to think of abstractions as a kind of external that is "written in" the PureData "language".
Oops, clarifying a bit: I mean that I second your opinion and that the abstractions ought to be in extra/ just like C/C++ externals are. To me, the purpose of multiple paths is for separating extras according to their origin: e.g. 1. the ones from the Pd installer; 2. the ones from other public origins; 3. private user-specific or project-specific extras.
But my question remains,
BTW I'd like to know how to set a help file for an abstraction that is not just the abstraction itself.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Oops, clarifying a bit: I mean that I second your opinion and that the abstractions ought to be in extra/ just like C/C++ externals are. To me, the purpose of multiple paths is for separating extras according to their origin: e.g. 1. the ones from the Pd installer; 2. the ones from other public origins; 3. private user-specific or project-specific extras.
I agree partly, but I would prefer a special path for abstractions. The reason simply is, that my extra-directory already is very large.
But my question remains,
BTW I'd like to know how to set a help file for an abstraction that is not just the abstraction itself.
Add "-help" before the ".pd" part and either have it next to the original file or in a directory in your help-path.
It's a bit more complicated if you use "Geiger"-namespaces (abstractions to be used in combination with the parent directory name like "rrad/fm2~" ), because then the "next to file" version won't work (or rather: it would, but not using the namespace anymore introducing possible nameclashes again). You need to add it into a subdirectory of a help-path-directory using the same namespace name then.
Example
Directory structure:
/abs /abs/rrad /abs/help/rrad
Files:
/abs/rrad/fm2~.pd /abs/help/rrad/fm2~-help.pd
$ pd -path /abs -helppath /abs/help
If you now create a [rrad/fm2~] object and open its "Help", it will open /abs/help/rrad/fm2~-help.pd if I remember all this correctly.
I still have to do some more testing, but if everything works reliably that way I intend to change the RRADical patches to use a structure like that.
Ciao
But my question remains,
BTW I'd like to know how to set a help file for an abstraction that is not just the abstraction itself.
For instance, in extra, there's a "complex-mod~.pd" (an abstraction); the help file is "help-complex-mod~.pd".
But perhaps you are asking how to control the help file name, so that several abstractions could share the same help file? I don't know any way to do this.
cheers Miller
Mathieu Bouchard http://artengine.ca/matju
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
Miller Puckette