Dear pd-dev,
When pd searches for a help file in response to "right-click Help" on some external object, the '~' is removed from the sought filename. This seems incorrect since it prevents "signal-based" and "message-based" objects from having the same root name. I would think the '~' should be fundamentally a part of the module's name.
My current workaround is to install a symbolic link from "help-name~.pd" to "help-name.pd" in my doc dir for externals, which seems rather ugly.
On a related topic, it would be nice if there were a standard recommended place to install such help files for pd extensions, e.g., /usr/local/lib/pd/doc/5.reference/extensions/<packagename>/. (I have seen /usr/local/lib/pd/doc/5.reference/<packagename>[help]/ used by some packages.)
Similarly, it would also be helpful to have a standard recommended directory for installation of externals (and libraries of externals), such as /usr/local/lib/pd/extensions/<package-name>/. I have seen /usr/local/lib/pd/<package-name>/ used by some packages, which leaves it unclear what is an extension and what is native pd.
-- Julius
Hallo, Julius Smith hat gesagt: // Julius Smith wrote:
On a related topic, it would be nice if there were a standard recommended place to install such help files for pd extensions, e.g., /usr/local/lib/pd/doc/5.reference/extensions/<packagename>/. (I have seen /usr/local/lib/pd/doc/5.reference/<packagename>[help]/ used by some packages.)
Similarly, it would also be helpful to have a standard recommended directory for installation of externals (and libraries of externals), such as /usr/local/lib/pd/extensions/<package-name>/. I have seen /usr/local/lib/pd/<package-name>/ used by some packages, which leaves it unclear what is an extension and what is native pd.
Actually all externals are an extension to Pd. On the CVS distribution build, every external is install to /usr/[local/]lib/pd/extra/ all docs go to doc/5.reference/ without subfolders. I think, installing all binaries in one directory makes things very easy to understand and setup.
ciao
On Tuesday 27 January 2004 04:19, Frank Barknecht wrote:
Actually all externals are an extension to Pd. On the CVS distribution build, every external is install to /usr/[local/]lib/pd/extra/ all docs go to doc/5.reference/ without subfolders. I think, installing all binaries in one directory makes things very easy to understand and setup.
ciao
It would be truly wonderfull if PD could adopt some sort of standard directory scheme - currently I have externs, libraries, and documentation patches all over the place, and my .pdrc is a mess.
Incidently, I think the CVS build put my doc in /usr/local/lib/doc... and not doc/... as you say; although some makefiles have indeed put their example patches in my home directory.
Currently it looks like most of my stuff has gravitated to /usr/local/lib/pd. In that directory I have "bin", "doc", "externs", "extra", and "flext".
It would really be nice if there were some sort of guidlelines in the PD documentation (or maybe there are and I just haven't rebrowsed lately),.
My way of working lately is to just hack the makefiles to put everything where most of the PD stuff seems to already be :-)
Larry
[Larry Troxler]->[Re: [PD-dev] Help search; standard external installation...
|On Tuesday 27 January 2004 04:19, Frank Barknecht wrote: |> |> Actually all externals are an extension to Pd. On the CVS distribution |> build, every external is install to /usr/[local/]lib/pd/extra/ all |> docs go to doc/5.reference/ without subfolders. I think, installing |> all binaries in one directory makes things very easy to understand and |> setup. |> |> ciao | |It would be truly wonderfull if PD could adopt some sort of standard directory |scheme - currently I have externs, libraries, and documentation patches all |over the place, and my .pdrc is a mess. | |Incidently, I think the CVS build put my doc in /usr/local/lib/doc... and not |doc/... as you say; although some makefiles have indeed put their example |patches in my home directory. | |Currently it looks like most of my stuff has gravitated to /usr/local/lib/pd. |In that directory I have "bin", "doc", "externs", "extra", and "flext". | |It would really be nice if there were some sort of guidlelines in the PD |documentation (or maybe there are and I just haven't rebrowsed lately),. | |My way of working lately is to just hack the makefiles to put everything where |most of the PD stuff seems to already be :-)
this is basically a matter of getting a prefix parameter into the install setup. pd itself handles this well with ./configure --prefix=... i prefer /usr because of debian conventions and the other popular option seems to be /usr/local. i think choice is the best option as opposed to one standardized hardcoded path.
not many/all externals (like my own) do this though if they have a configure script or install target at all so you have to edit the makefile. could def. be improved.
On Sunday 01 February 2004 18:38, d.lj wrote:
[Larry Troxler]->[Re: [PD-dev] Help search; standard external installation...
this is basically a matter of getting a prefix parameter into the install setup. pd itself handles this well with ./configure --prefix=... i prefer /usr because of debian conventions and the other popular option seems to be /usr/local. i think choice is the best option as opposed to one standardized hardcoded path.
not many/all externals (like my own) do this though if they have a configure script or install target at all so you have to edit the makefile. could def. be improved.
Hmm, I had thought that this was more than just a choice between /usr/* and /usr/local/*.
Maybe everything's getting sorted out lately, and I just have some really old stuff lying around. Certainly I wouldn't complain about /usr/* vs. /usr/local/* if it were certain what the structure was underneath.
Looking at my .pdrc below, I guess that a lot of makefiles havent't really included "install" targets, or else I didn't bother to use them. Truth to be told, I should prune this thing, and maybe things are getting better and some of these paths are now empty.
But still, remaning suspects are the vasp and iemlib* libraries.
Larry ---
-path cur -path pd -path pd/util -path pd/test -path pd/ins -path pd/help -path /usr/lib/pd/externs -path /usr/local/lib/pd/externs -path /usr/lib/pd/extra -path /usr/local/lib/pd/extra/vasp/pd -path k_quile -lib xeq/xeq -lib /usr/lib/pd/extra/iemlib1 -lib /usr/lib/pd/extra/iemlib2 -lib vasp/vasp
On Sun, 1 Feb 2004, Larry Troxler wrote:
not many/all externals (like my own) do this though if they have a configure script or install target at all so you have to edit the makefile. could def. be improved.
One of the goals of the CVS was to have a common structure w/ makefiles and common places. There are other more subtile problems in several of the makefiles of the externals, like not using -fPIC etc, problems of compilation on some architectures, libraries etc.
One attempt to solve this was the build/<arch> structure that is in CVS, but I am not really happy with that, and it only works partly. I can't think of a better solution, well not unless the developers start to work closer together, which would mean more communication overhead.
The places the externals get installed to currently (/usr/lib and /usr/local/lib) are the official places of the FHS, the Filesystem Hierarchy Standard (see http://www.pathname.com/fhs/), which among other things says that locally compiled packages should go into /usr/local, whereas packages that come with the distribution go into the /usr tree.
I suggest that we put all the externals and libraries in ../lib/pd/extra. Of course we have to resolve the name conflicts then, which would be a good idea in general.
After all we have to put more administrative work into the CVS, something I have been trying to do, but I am not very good at it, it's just too boring ... (well, thats probably why only a few of the developers show interest for these problems, some are downright fighting each attempt to come up with a common structure .. well, what can we do ? )
Guenter
Hmm, I had thought that this was more than just a choice between /usr/* and /usr/local/*.
Maybe everything's getting sorted out lately, and I just have some really old stuff lying around. Certainly I wouldn't complain about /usr/* vs. /usr/local/* if it were certain what the structure was underneath.
Looking at my .pdrc below, I guess that a lot of makefiles havent't really included "install" targets, or else I didn't bother to use them. Truth to be told, I should prune this thing, and maybe things are getting better and some of these paths are now empty.
But still, remaning suspects are the vasp and iemlib* libraries.
Larry
-path cur -path pd -path pd/util -path pd/test -path pd/ins -path pd/help -path /usr/lib/pd/externs -path /usr/local/lib/pd/externs -path /usr/lib/pd/extra -path /usr/local/lib/pd/extra/vasp/pd -path k_quile -lib xeq/xeq -lib /usr/lib/pd/extra/iemlib1 -lib /usr/lib/pd/extra/iemlib2 -lib vasp/vasp
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo,
guenter geiger hat gesagt: // guenter geiger wrote:
I suggest that we put all the externals and libraries in ../lib/pd/extra. Of course we have to resolve the name conflicts then, which would be a good idea in general.
After all we have to put more administrative work into the CVS, something I have been trying to do, but I am not very good at it, it's just too boring ... (well, thats probably why only a few of the developers show interest for these problems, some are downright fighting each attempt to come up with a common structure .. well, what can we do ? )
We aren't that many as there are maintainers in Debian, but still I think, that this will only get solved at last by having a written policy for externals in CVS, that all developers agree upon and then we could adapt everything to follow that policy.
There are some hairy issues involved. For example, packaging would be much easier, if the policy would not allow libraries, but several developers think, that under certain circumstances libraries are a good thing.
I think, that the location of externals and help files is rather easy to agree upon. As this is cross-platform development, we need to find a way to abstract out the Pd directory, by, say, using an environment variable PDDIR or a define while building the externals. Then this would specify, where everything goes relative to that setting.
ciao
On Mon, 2 Feb 2004, Frank Barknecht wrote:
We aren't that many as there are maintainers in Debian, but still I think, that this will only get solved at last by having a written policy for externals in CVS, that all developers agree upon and then we could adapt everything to follow that policy.
There are some hairy issues involved. For example, packaging would be much easier, if the policy would not allow libraries, but several developers think, that under certain circumstances libraries are a good thing.
Yes, and I think I do understand very well their motives. We have to accept that it is this way, and the best thing would be to split the externals section into externals and libraries.
Externals would be a place to put single externals, together with a policy, that we would have to define.
The libraries section is the one for those who want to cook their own soup :)
I think, that the location of externals and help files is rather easy to agree upon. As this is cross-platform development, we need to find a way to abstract out the Pd directory, by, say, using an environment variable PDDIR or a define while building the externals. Then this would specify, where everything goes relative to that setting.
Well, yes, I think that most of the packages offer an abstraction of the PDDIR, the problem is that they don't do it the same way, and that they have different defaults ...
Guenter
ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
[Frank Barknecht]->[Re: [PD-dev] Help search; standard external...
|Hallo, | |guenter geiger hat gesagt: // guenter geiger wrote: | |> I suggest that we put all the externals and libraries in ../lib/pd/extra. |> Of course we have to resolve the name conflicts then, which would be a |> good idea in general. |> |> After all we have to put more administrative work into the CVS, something |> I have been trying to do, but I am not very good at it, it's just too |> boring ... (well, thats probably why only a few of the developers show |> interest for these problems, some are downright fighting each attempt |> to come up with a common structure .. well, what can we do ? ) | |We aren't that many as there are maintainers in Debian, but still I |think, that this will only get solved at last by having a written |policy for externals in CVS, that all developers agree upon and then |we could adapt everything to follow that policy. | |There are some hairy issues involved. For example, packaging would be |much easier, if the policy would not allow libraries, but several |developers think, that under certain circumstances libraries are a |good thing. | |I think, that the location of externals and help files is rather easy |to agree upon. As this is cross-platform development, we need to find |a way to abstract out the Pd directory, by, say, using an environment |variable PDDIR or a define while building the externals. Then this |would specify, where everything goes relative to that setting.
hy all.
i m not sure if such a policy is the key to this dilemma given guenthers statement of resistance against structuring, since its only more of structuring, more specifically a top-down structuring and i think the other way round would be preferable.
the cvs right now fullfils at least the function of a more or less complete collection spot for externals regardless of the state they're in, which is pretty good, so exlcuding stuff via some policy will only generate regress in this aspect. i think the same goes for using libaries in externals.
a lot of stuff is being created by a devel-user hybrid and commitment stops if a local solution is achieved, i.e. bringing a little project into some formal shape is a bunch of work with no more direct benefit.
maybe a proper example external would help here, since a lot of stuff is being made via copy and pasting from existing externals.
this means that the work fixing makefiles and putting stuff into common locations is being shifted to those packaging stuff for particular distribution formats. but exactly the work thats being done there could be folded back into the cvs?
i dont think that agreeing on any general common location for stuff is necessary as long as there's a configure script providing a --prefix option.
furthermore, i dont think its productive to moan about stuff being strewn all over the place. just have a quick glance over the stuff you're compiling and you can figure where make install will put it. if there's no install target at all, its even more your responsibility to pass in the proper path when doing a cp *.pd_platform /path/to/pd/externs
i do install a lot of externals here and there and somehow i manage to get them all under /usr/lib/pd and i m not applying any kind of voodoo or excessively timeconsuming techniques to achieve this, which is not to say that i dont (massively) appreciate doing "cvs co externals" instead of clicking 20 plus websites and downloading tar.gz's.
and given that probably most "users" use binary packages anyway its again back to the responsibility of the package maintainer.
i think this boils down to: if you think you can fix something, fix it and commit it.
if not, spend money on a commercial package or hire someone to fix it for you.
make sense? make: *** No rule to make target `sense'. Stop.
bst,jdl
Hallo, d.lj hat gesagt: // d.lj wrote:
[Frank Barknecht]->[Re: [PD-dev] Help search; standard external... i m not sure if such a policy is the key to this dilemma given guenthers statement of resistance against structuring, since its only more of structuring, more specifically a top-down structuring and i think the other way round would be preferable.
the cvs right now fullfils at least the function of a more or less complete collection spot for externals regardless of the state they're in, which is pretty good, so exlcuding stuff via some policy will only generate regress in this aspect. i think the same goes for using libaries in externals.
a lot of stuff is being created by a devel-user hybrid and commitment stops if a local solution is achieved, i.e. bringing a little project into some formal shape is a bunch of work with no more direct benefit.
maybe a proper example external would help here, since a lot of stuff is being made via copy and pasting from existing externals.
this means that the work fixing makefiles and putting stuff into common locations is being shifted to those packaging stuff for particular distribution formats. but exactly the work thats being done there could be folded back into the cvs?
Well, maybe policy is a too strong word. As I am a Makefile and autoconf idiot, I am a prime example of those copy and paste guys: I just use the same system, that Thomas uses in the flext-tutorials. (I would love to see an autoconf example for flext exernals. I will adapt it immediatly.)
If everyone was using autoconf, we would have no problems. It gets difficult, when Makefiles are using DESTDIR, PDDIR or whatever as install target. Yes, if you compile everything separately, this is fine: just look into the Makefile, search for install and edit it. But this is tedious work, so an agreement on, say, using PDDIR as install path would help a lot.
Oh: And I don't want to forbid libraries, but they will have to be dealt with differently than single externals and they are more prone to carry undiscovered name clashes.
ciao
i think settling on PDDIR is a good start.
autoconf for the nearer future.
re: libraries: there's a misunderstanding since i was thinking of libraries as in liblame.so etc and not as in OSC.pd_linux
but still, having 500 single files in the externs dir is a bit messy too when you only have, say, 10 packages installed. for large packages libraries kind of do make sense but anyway ..
re name-clashes: if there are clashes, one install will just overwrite an older install of an object of the same name, so you ll still have to start searching which overwrote what. only after you found it, its easier to choose which one you want to use.
ynk,j
[Frank Barknecht]->[Re: [PD-dev] installation paths]->[04-02-02 16:33]
|Well, maybe policy is a too strong word. As I am a Makefile and |autoconf idiot, I am a prime example of those copy and paste guys: I |just use the same system, that Thomas uses in the flext-tutorials. |(I would love to see an autoconf example for flext exernals. I will |adapt it immediatly.) | |If everyone was using autoconf, we would have no problems. It gets |difficult, when Makefiles are using DESTDIR, PDDIR or whatever as |install target. Yes, if you compile everything separately, this is |fine: just look into the Makefile, search for install and edit it. But |this is tedious work, so an agreement on, say, using PDDIR as install |path would help a lot. | |Oh: And I don't want to forbid libraries, but they will have to be |dealt with differently than single externals and they are more prone |to carry undiscovered name clashes. | |ciao |
Hallo, d.lj hat gesagt: // d.lj wrote:
re name-clashes: if there are clashes, one install will just overwrite an older install of an object of the same name, so you ll still have to start searching which overwrote what. only after you found it, its easier to choose which one you want to use.
Well, name clashes are harder to get rid of, if something clashes with an external inside an external library. For example: iemlib has prepend and gate, which also are in Cyclone. I prefer Cyclone here because it works as in Max, but now I either have to recompile iemlib or move iemlib out of the way. Bun then I can not use the IEM filters!
ciao
Well, maybe policy is a too strong word. As I am a Makefile and autoconf idiot, I am a prime example of those copy and paste guys: I just use the same system, that Thomas uses in the flext-tutorials. (I would love to see an autoconf example for flext exernals. I will adapt it immediatly.)
Actually, i'm currently working out a new build system for the flext library and flext externals, based on central make includes (in the flext folder) and only small makefiles for the actual externals. I'll put it in the cvs soon. Since i don't have experiences with automake ot autoconf i'd appreciate any related support.
best greetings, Thomas
On Mon, 2 Feb 2004, d.lj wrote:
i m not sure if such a policy is the key to this dilemma given guenthers statement of resistance against structuring, since its only more of structuring, more specifically a top-down structuring and i think the other way round would be preferable.
I think a common build system for all platforms (where the developers just have to drop in their external) and some basic guideline how to do it would not necessarily be restrictive.
It would rather help the developers. They just would not need to think about the build system anymore, and if something in the install paths changes (e.g. we decide to split the externals in subdirectories) it would happen in an organized way and easy to communicate to users.
Guenter
the cvs right now fullfils at least the function of a more or less complete collection spot for externals regardless of the state they're in, which is pretty good, so exlcuding stuff via some policy will only generate regress in this aspect. i think the same goes for using libaries in externals.
a lot of stuff is being created by a devel-user hybrid and commitment stops if a local solution is achieved, i.e. bringing a little project into some formal shape is a bunch of work with no more direct benefit.
maybe a proper example external would help here, since a lot of stuff is being made via copy and pasting from existing externals.
this means that the work fixing makefiles and putting stuff into common locations is being shifted to those packaging stuff for particular distribution formats. but exactly the work thats being done there could be folded back into the cvs?
i dont think that agreeing on any general common location for stuff is necessary as long as there's a configure script providing a --prefix option.
furthermore, i dont think its productive to moan about stuff being strewn all over the place. just have a quick glance over the stuff you're compiling and you can figure where make install will put it. if there's no install target at all, its even more your responsibility to pass in the proper path when doing a cp *.pd_platform /path/to/pd/externs
i do install a lot of externals here and there and somehow i manage to get them all under /usr/lib/pd and i m not applying any kind of voodoo or excessively timeconsuming techniques to achieve this, which is not to say that i dont (massively) appreciate doing "cvs co externals" instead of clicking 20 plus websites and downloading tar.gz's.
and given that probably most "users" use binary packages anyway its again back to the responsibility of the package maintainer.
i think this boils down to: if you think you can fix something, fix it and commit it.
if not, spend money on a commercial package or hire someone to fix it for you.
make sense? make: *** No rule to make target `sense'. Stop.
bst,jdl
-- i x D � � o r G GPG-key at http://xdv.org/~jdl/jdl.pub.asc
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Monday, Feb 2, 2004, at 16:03 America/New_York, guenter geiger wrote:
On Mon, 2 Feb 2004, d.lj wrote:
i m not sure if such a policy is the key to this dilemma given guenthers statement of resistance against structuring, since its only more of structuring, more specifically a top-down structuring and i think the other way round would be preferable.
I think a common build system for all platforms (where the developers just have to drop in their external) and some basic guideline how to do it would not necessarily be restrictive.
It would rather help the developers. They just would not need to think about the build system anymore, and if something in the install paths changes (e.g. we decide to split the externals in subdirectories) it would happen in an organized way and easy to communicate to users.
Guenter
This is definitely the best approach. Instead of a policy, we could define an 'interface' that a developer would need to implement in order for their externals to be included in the packages. For example, in order to have your externals included in the MacOS X installer, you would need to implement "make pkg", which would compile everything in that externals collection and generate a MacOS X package to be included in the installer.
In order for this to work, there would need to be some standard make targets and a standard internal layout for Pd, with $PDDIR being freely redefinable (/usr, /usr/local, /Applications, C:\Program Files, etc.). Here a suggested internal layout based on what exists:
abstractions bin doc 0.tutorials/ 1.manual/ 2.control.examples/ 3.audio.examples/ 4.fft.examples/ 5.reference/ 6.externals flext/ GEM/ 7.stuff/ sound/ extra lib (for external libraries)
Another thing is to have a suggested file layout for developer's files, so that the paths to the pd sources, for example, are the same for everyone. I think most people basically are doing it the same way now, but I'll lay it out just for discussion's sake. I think everything should be laid out as if you just run 'cvs checkout' for everything in the same dir:
abstractions doc externals packages pd
I would ultimately like to see various 'extensions' to pd in this tree also, maybe in a directory/cvs module called 'extensions':
extensions Gem GemLibs Framestein gripd xgui etc. etc.
I think the key to making this work with the pd community is not making it a 'requirement' for the CVS per se. Instead a developer will have to provide the standard interface to the package makers in order for the maintainers to include their externals in the packages. I would love to be able to include every piece of software written for Pd in the installers, but I do not have time or an inclination to figure out each individual build system. But if someone else wants to include it in the build systems themselves, they can.
The other key is providing clear examples and documentation about the standard interfaces and path layout. I am guilty of not doing this yet for sure, but I do think its quite important and will start working on it while I working making new installers for 0.37-1.
.hc
the cvs right now fullfils at least the function of a more or less complete collection spot for externals regardless of the state they're in, which is pretty good, so exlcuding stuff via some policy will only generate regress in this aspect. i think the same goes for using libaries in externals.
a lot of stuff is being created by a devel-user hybrid and commitment stops if a local solution is achieved, i.e. bringing a little project into some formal shape is a bunch of work with no more direct benefit.
maybe a proper example external would help here, since a lot of stuff is being made via copy and pasting from existing externals.
this means that the work fixing makefiles and putting stuff into common locations is being shifted to those packaging stuff for particular distribution formats. but exactly the work thats being done there could be folded back into the cvs?
i dont think that agreeing on any general common location for stuff is necessary as long as there's a configure script providing a --prefix option.
furthermore, i dont think its productive to moan about stuff being strewn all over the place. just have a quick glance over the stuff you're compiling and you can figure where make install will put it. if there's no install target at all, its even more your responsibility to pass in the proper path when doing a cp *.pd_platform /path/to/pd/externs
i do install a lot of externals here and there and somehow i manage to get them all under /usr/lib/pd and i m not applying any kind of voodoo or excessively timeconsuming techniques to achieve this, which is not to say that i dont (massively) appreciate doing "cvs co externals" instead of clicking 20 plus websites and downloading tar.gz's.
and given that probably most "users" use binary packages anyway its again back to the responsibility of the package maintainer.
i think this boils down to: if you think you can fix something, fix it and commit it.
if not, spend money on a commercial package or hire someone to fix it for you.
make sense? make: *** No rule to make target `sense'. Stop.
bst,jdl
-- i x D ¥ · o r G GPG-key at http://xdv.org/~jdl/jdl.pub.asc
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
________________________________________________________________________ ____
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 Fri, 6 Feb 2004, Hans-Christoph Steiner wrote:
This is definitely the best approach. Instead of a policy, we could define an 'interface' that a developer would need to implement in order for their externals to be included in the packages. For example, in order to have your externals included in the MacOS X installer, you would need to implement "make pkg", which would compile everything in that externals collection and generate a MacOS X package to be included in the installer.
Hi, actually thought that the external developers do not provide any build system whatsoever (I do not know how to create an MacOS X package, so I would fail to follow your interface).
I was rather thinking to do it in a similar way as the build system. e.g.
each external provides: 1 c-file with the code 1 .txt file, with an easily parseable description that will be automatically transformed into online documentation 1 .pd file with the documentation.
A developer drops this into the external pool, then the external gets automatically compiled on all architectures and results get send to the uploader.
In order for this to work, there would need to be some standard make targets and a standard internal layout for Pd, with $PDDIR being freely redefinable (/usr, /usr/local, /Applications, C:\Program Files, etc.). Here a suggested internal layout based on what exists:
abstractions bin doc 0.tutorials/ 1.manual/ 2.control.examples/ 3.audio.examples/ 4.fft.examples/ 5.reference/ 6.externals flext/ GEM/ 7.stuff/ sound/ extra lib (for external libraries)
This seems to be basically ok, although I do not fully understand what the "flext" and "GEM" entries in 6.externals means. Should this be the place to put examples ?
Another thing is to have a suggested file layout for developer's files, so that the paths to the pd sources, for example, are the same for everyone. I think most people basically are doing it the same way now, but I'll lay it out just for discussion's sake. I think everything should be laid out as if you just run 'cvs checkout' for everything in the same dir:
abstractions doc externals packages pd
I would ultimately like to see various 'extensions' to pd in this tree also, maybe in a directory/cvs module called 'extensions':
extensions Gem GemLibs Framestein gripd xgui etc. etc.
I think the key to making this work with the pd community is not making it a 'requirement' for the CVS per se. Instead a developer will have to provide the standard interface to the package makers in order for the maintainers to include their externals in the packages. I would love to be able to include every piece of software written for Pd in the installers, but I do not have time or an inclination to figure out each individual build system. But if someone else wants to include it in the build systems themselves, they can.
The other key is providing clear examples and documentation about the standard interfaces and path layout. I am guilty of not doing this yet for sure, but I do think its quite important and will start working on it while I working making new installers for 0.37-1.
Everything you have done until now was great, and it helps the pd users a lot. No reason to feel guilty :)
Guenter
the cvs right now fullfils at least the function of a more or less complete collection spot for externals regardless of the state they're in, which is pretty good, so exlcuding stuff via some policy will only generate regress in this aspect. i think the same goes for using libaries in externals.
a lot of stuff is being created by a devel-user hybrid and commitment stops if a local solution is achieved, i.e. bringing a little project into some formal shape is a bunch of work with no more direct benefit.
maybe a proper example external would help here, since a lot of stuff is being made via copy and pasting from existing externals.
this means that the work fixing makefiles and putting stuff into common locations is being shifted to those packaging stuff for particular distribution formats. but exactly the work thats being done there could be folded back into the cvs?
i dont think that agreeing on any general common location for stuff is necessary as long as there's a configure script providing a --prefix option.
furthermore, i dont think its productive to moan about stuff being strewn all over the place. just have a quick glance over the stuff you're compiling and you can figure where make install will put it. if there's no install target at all, its even more your responsibility to pass in the proper path when doing a cp *.pd_platform /path/to/pd/externs
i do install a lot of externals here and there and somehow i manage to get them all under /usr/lib/pd and i m not applying any kind of voodoo or excessively timeconsuming techniques to achieve this, which is not to say that i dont (massively) appreciate doing "cvs co externals" instead of clicking 20 plus websites and downloading tar.gz's.
and given that probably most "users" use binary packages anyway its again back to the responsibility of the package maintainer.
i think this boils down to: if you think you can fix something, fix it and commit it.
if not, spend money on a commercial package or hire someone to fix it for you.
make sense? make: *** No rule to make target `sense'. Stop.
bst,jdl
-- i x D � � o r G GPG-key at http://xdv.org/~jdl/jdl.pub.asc
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
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
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Sun, 8 Feb 2004, guenter geiger wrote:
On Fri, 6 Feb 2004, Hans-Christoph Steiner wrote:
This is definitely the best approach. Instead of a policy, we could define an 'interface' that a developer would need to implement in order for their externals to be included in the packages. For example, in order to have your externals included in the MacOS X installer, you would need to implement "make pkg", which would compile everything in that externals collection and generate a MacOS X package to be included in the installer.
Hi, actually thought that the external developers do not provide any build system whatsoever (I do not know how to create an MacOS X package, so I would fail to follow your interface).
Yes, I think it would be great if all of the externals people used the same build system. But many do not, and there are other things, like xgui, gripd, etc. which does seem to fit into the externals tree. Currently the build system has been created by a handful of maintainers basically, but I think if we document it well enough, then external-developers will do the work themselves.
I was rather thinking to do it in a similar way as the build system. e.g.
each external provides: 1 c-file with the code 1 .txt file, with an easily parseable description that will be automatically transformed into online documentation 1 .pd file with the documentation.
A developer drops this into the external pool, then the external gets automatically compiled on all architectures and results get send to the uploader.
Yeah, this is exactly what I am was trying to say, but I guess not so clearly. This is a basic specification for an 'interface' to the externals build system.
In order for this to work, there would need to be some standard make targets and a standard internal layout for Pd, with $PDDIR being freely redefinable (/usr, /usr/local, /Applications, C:\Program Files, etc.). Here a suggested internal layout based on what exists:
abstractions bin doc 0.tutorials/ 1.manual/ 2.control.examples/ 3.audio.examples/ 4.fft.examples/ 5.reference/ 6.externals flext/ GEM/ 7.stuff/ sound/ extra lib (for external libraries)
This seems to be basically ok, although I do not fully understand what the "flext" and "GEM" entries in 6.externals means. Should this be the place to put examples ?
Flext has a bunch of READMEs and license files, GEM has its own manuals, tutorials, etc. It would be nice to have all this stuff organized so that people can find it. Right now, the organization is very rough. For example, "7.stuff" doesn't really tell yo much about what's in there and "6.externs" only has the really basic writing-externals objects.
.hc
Another thing is to have a suggested file layout for developer's files, so that the paths to the pd sources, for example, are the same for everyone. I think most people basically are doing it the same way now, but I'll lay it out just for discussion's sake. I think everything should be laid out as if you just run 'cvs checkout' for everything in the same dir:
abstractions doc externals packages pd
I would ultimately like to see various 'extensions' to pd in this tree also, maybe in a directory/cvs module called 'extensions':
extensions Gem GemLibs Framestein gripd xgui etc. etc.
I think the key to making this work with the pd community is not making it a 'requirement' for the CVS per se. Instead a developer will have to provide the standard interface to the package makers in order for the maintainers to include their externals in the packages. I would love to be able to include every piece of software written for Pd in the installers, but I do not have time or an inclination to figure out each individual build system. But if someone else wants to include it in the build systems themselves, they can.
The other key is providing clear examples and documentation about the standard interfaces and path layout. I am guilty of not doing this yet for sure, but I do think its quite important and will start working on it while I working making new installers for 0.37-1.
Everything you have done until now was great, and it helps the pd users a lot. No reason to feel guilty :)
Guenter
the cvs right now fullfils at least the function of a more or less complete collection spot for externals regardless of the state they're in, which is pretty good, so exlcuding stuff via some policy will only generate regress in this aspect. i think the same goes for using libaries in externals.
a lot of stuff is being created by a devel-user hybrid and commitment stops if a local solution is achieved, i.e. bringing a little project into some formal shape is a bunch of work with no more direct benefit.
maybe a proper example external would help here, since a lot of stuff is being made via copy and pasting from existing externals.
this means that the work fixing makefiles and putting stuff into common locations is being shifted to those packaging stuff for particular distribution formats. but exactly the work thats being done there could be folded back into the cvs?
i dont think that agreeing on any general common location for stuff is necessary as long as there's a configure script providing a --prefix option.
furthermore, i dont think its productive to moan about stuff being strewn all over the place. just have a quick glance over the stuff you're compiling and you can figure where make install will put it. if there's no install target at all, its even more your responsibility to pass in the proper path when doing a cp *.pd_platform /path/to/pd/externs
i do install a lot of externals here and there and somehow i manage to get them all under /usr/lib/pd and i m not applying any kind of voodoo or excessively timeconsuming techniques to achieve this, which is not to say that i dont (massively) appreciate doing "cvs co externals" instead of clicking 20 plus websites and downloading tar.gz's.
and given that probably most "users" use binary packages anyway its again back to the responsibility of the package maintainer.
i think this boils down to: if you think you can fix something, fix it and commit it.
if not, spend money on a commercial package or hire someone to fix it for you.
make sense? make: *** No rule to make target `sense'. Stop.
bst,jdl
-- i x D ¥ · o r G GPG-key at http://xdv.org/~jdl/jdl.pub.asc
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
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
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
zen \ \ \[D[D[D[D
[Julius Smith]->[[PD-dev] Help search; standard external installation...
|Dear pd-dev, | |When pd searches for a help file in response to "right-click Help" on some |external object, the '~' is removed from the sought filename. This seems |incorrect since it prevents "signal-based" and "message-based" objects from |having the same root name. I would think the '~' should be fundamentally a |part of the module's name. | |My current workaround is to install a symbolic link from "help-name~.pd" to |"help-name.pd" in my doc dir for externals, which seems rather ugly.
the help file can be set: http://iem.kug.ac.at/pd/externals-HOWTO/node9.html#SECTION000921000000000000...
d.lj wrote:
[Julius Smith]->[[PD-dev] Help search; standard external installation...
|Dear pd-dev, | |My current workaround is to install a symbolic link from "help-name~.pd" to |"help-name.pd" in my doc dir for externals, which seems rather ugly.
the help file can be set: http://iem.kug.ac.at/pd/externals-HOWTO/node9.html#SECTION000921000000000000...
and indeed i should make an update, to reflect recent (and not so recent) changes of pd...(like the "help-" prefixes)
mfg.a.sdr IOhannes
Thanks for the help. Is there a recommended way to access this function [class_sethelpsymbol(t_class *c, t_symbol *s)] via flext?
It still seems to me that the default behavior (removing the tilde) is incorrect.
Julius
At 02:48 AM 1/27/2004, d.lj wrote:
[Julius Smith]->[[PD-dev] Help search; standard external installation...
|Dear pd-dev, | |When pd searches for a help file in response to "right-click Help" on some |external object, the '~' is removed from the sought filename. This seems |incorrect since it prevents "signal-based" and "message-based" objects from |having the same root name. I would think the '~' should be fundamentally a |part of the module's name. | |My current workaround is to install a symbolic link from "help-name~.pd" to |"help-name.pd" in my doc dir for externals, which seems rather ugly.
the help file can be set: http://iem.kug.ac.at/pd/externals-HOWTO/node9.html#SECTION000921000000000000...
-- X d U . o R G GPG-key at http://xdv.org/~jdl/jdl.pub.asc
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
_____________________________ Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
Hallo, Julius Smith hat gesagt: // Julius Smith wrote:
Thanks for the help. Is there a recommended way to access this function [class_sethelpsymbol(t_class *c, t_symbol *s)] via flext?
It still seems to me that the default behavior (removing the tilde) is incorrect.
I think it's "flext_obj::DefineHelp" defined in flbase.cpp I tend to avoid this though, because I prefer to just use the default behaviour, not because it would be the correct thing to do, but because of ease of maintainance: If someone (Miller) decides, that for example not removing the tilde is better, I wouldn't need to change the source code, I'd just rename the help file.
I actually agree that retaining the tilde is better, because it avoids conflicts between non- and signal externals which carry the same name (like cos and cos~)
ciao
Hi Julius,
I can't find where the tilde is getting deleted... I just got help for the extern "fiddle~" which picked up "help-fiddle~.pd" correctly. So I have no idea what's going on here...
cheers Miller
On Tue, Jan 27, 2004 at 11:53:04AM -0800, Julius Smith wrote:
Thanks for the help. Is there a recommended way to access this function [class_sethelpsymbol(t_class *c, t_symbol *s)] via flext?
It still seems to me that the default behavior (removing the tilde) is incorrect.
Julius
At 02:48 AM 1/27/2004, d.lj wrote:
[Julius Smith]->[[PD-dev] Help search; standard external installation...
|Dear pd-dev, | |When pd searches for a help file in response to "right-click Help" on some |external object, the '~' is removed from the sought filename. This seems |incorrect since it prevents "signal-based" and "message-based" objects from |having the same root name. I would think the '~' should be fundamentally a |part of the module's name. | |My current workaround is to install a symbolic link from "help-name~.pd" to |"help-name.pd" in my doc dir for externals, which seems rather ugly.
the help file can be set: http://iem.kug.ac.at/pd/externals-HOWTO/node9.html#SECTION000921000000000000...
-- X d U . o R G GPG-key at http://xdv.org/~jdl/jdl.pub.asc
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hi Miller,
Hmmm, it sounds like I must have a special problem of some kind. I'll go after it on my machine (a Red Hat 9 Linux system) and report back.
Thanks, Julius
At 05:12 PM 2/6/2004, Miller Puckette wrote:
Hi Julius,
I can't find where the tilde is getting deleted... I just got help for the extern "fiddle~" which picked up "help-fiddle~.pd" correctly. So I have no idea what's going on here...
cheers Miller
On Tue, Jan 27, 2004 at 11:53:04AM -0800, Julius Smith wrote:
Thanks for the help. Is there a recommended way to access this function [class_sethelpsymbol(t_class *c, t_symbol *s)] via flext?
It still seems to me that the default behavior (removing the tilde) is incorrect.
Julius
At 02:48 AM 1/27/2004, d.lj wrote:
[Julius Smith]->[[PD-dev] Help search; standard external installation...
|Dear pd-dev, | |When pd searches for a help file in response to "right-click Help" on some |external object, the '~' is removed from the sought filename. This
seems
|incorrect since it prevents "signal-based" and "message-based" objects from |having the same root name. I would think the '~' should be fundamentally a |part of the module's name. | |My current workaround is to install a symbolic link from
"help-name~.pd"
to |"help-name.pd" in my doc dir for externals, which seems rather ugly.
the help file can be set: http://iem.kug.ac.at/pd/externals-HOWTO/node9.html#SECTION0009210000000
00000000
-- X d U . o R G GPG-key at http://xdv.org/~jdl/jdl.pub.asc
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
_____________________________ Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
Hi Julius, could this be a problem related to flext usage?
best greetings, Thomas
----- Original Message ----- From: "Julius Smith" jos@ccrma.stanford.edu To: msp@ucsd.edu Cc: "d.lj" jdl@xdv.org; "pd-dev" pd-dev@iem.kug.ac.at Sent: Saturday, February 07, 2004 9:33 AM Subject: Re: [PD-dev] Help search; standard external installation paths
Hi Miller,
Hmmm, it sounds like I must have a special problem of some kind. I'll go after it on my machine (a Red Hat 9 Linux system) and report back.
Thanks, Julius
At 05:12 PM 2/6/2004, Miller Puckette wrote:
Hi Julius,
I can't find where the tilde is getting deleted... I just got help for
the
extern "fiddle~" which picked up "help-fiddle~.pd" correctly. So I have no idea what's going on here...
cheers Miller
On Tue, Jan 27, 2004 at 11:53:04AM -0800, Julius Smith wrote:
Thanks for the help. Is there a recommended way to access this
function
[class_sethelpsymbol(t_class *c, t_symbol *s)] via flext?
It still seems to me that the default behavior (removing the tilde) is incorrect.
Julius
At 02:48 AM 1/27/2004, d.lj wrote:
[Julius Smith]->[[PD-dev] Help search; standard external
installation...
|Dear pd-dev, | |When pd searches for a help file in response to "right-click Help"
on
some |external object, the '~' is removed from the sought filename. This
seems
|incorrect since it prevents "signal-based" and "message-based"
objects
from |having the same root name. I would think the '~' should be fundamentally a |part of the module's name. | |My current workaround is to install a symbolic link from
"help-name~.pd"
to |"help-name.pd" in my doc dir for externals, which seems rather
ugly.
the help file can be set:
http://iem.kug.ac.at/pd/externals-HOWTO/node9.html#SECTION0009210000000
00000000
-- X d U . o R G GPG-key at http://xdv.org/~jdl/jdl.pub.asc
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hi Thomas,
It appears you are right. The problem disappears when I add the line
DefineHelp("name~");
inside the invocation of
FLEXT_NEW_DSP("name~",name)
in name~.cpp (more often called main.cpp).
Is this a flext bug?
Thanks, Julius
At 01:33 AM 2/7/2004, Thomas Grill wrote:
Hi Julius, could this be a problem related to flext usage?
best greetings, Thomas
----- Original Message ----- From: "Julius Smith" jos@ccrma.stanford.edu To: msp@ucsd.edu Cc: "d.lj" jdl@xdv.org; "pd-dev" pd-dev@iem.kug.ac.at Sent: Saturday, February 07, 2004 9:33 AM Subject: Re: [PD-dev] Help search; standard external installation paths
Hi Miller,
Hmmm, it sounds like I must have a special problem of some kind. I'll go after it on my machine (a Red Hat 9 Linux system) and report back.
Thanks, Julius
At 05:12 PM 2/6/2004, Miller Puckette wrote:
Hi Julius,
I can't find where the tilde is getting deleted... I just got help for
the
extern "fiddle~" which picked up "help-fiddle~.pd" correctly. So I have no idea what's going on here...
cheers Miller
On Tue, Jan 27, 2004 at 11:53:04AM -0800, Julius Smith wrote:
Thanks for the help. Is there a recommended way to access this
function
[class_sethelpsymbol(t_class *c, t_symbol *s)] via flext?
It still seems to me that the default behavior (removing the tilde) is incorrect.
Julius
At 02:48 AM 1/27/2004, d.lj wrote:
[Julius Smith]->[[PD-dev] Help search; standard external
installation...
|Dear pd-dev, | |When pd searches for a help file in response to "right-click Help"
on
some |external object, the '~' is removed from the sought filename. This
seems
|incorrect since it prevents "signal-based" and "message-based"
objects
from |having the same root name. I would think the '~' should be fundamentally a |part of the module's name. | |My current workaround is to install a symbolic link from
"help-name~.pd"
to |"help-name.pd" in my doc dir for externals, which seems rather
ugly.
the help file can be set:
http://iem.kug.ac.at/pd/externals-HOWTO/node9.html#SECTION0009210000000
00000000
-- X d U . o R G GPG-key at http://xdv.org/~jdl/jdl.pub.asc
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
_____________________________ Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
Hi Julius, that was indeed a flext bug. It is fixed in tomorrow's cvs.
best greetings, Thomas
----- Original Message ----- From: "Julius Smith" jos@ccrma.stanford.edu To: "Thomas Grill" t.grill@gmx.net Cc: msp@ucsd.edu; "d.lj" jdl@xdv.org; "pd-dev" pd-dev@iem.kug.ac.at Sent: Sunday, February 08, 2004 7:39 PM Subject: Re: [PD-dev] Help search; standard external installation paths
Hi Thomas,
It appears you are right. The problem disappears when I add the line
DefineHelp("name~");
inside the invocation of
FLEXT_NEW_DSP("name~",name)
in name~.cpp (more often called main.cpp).
Is this a flext bug?
Thanks, Julius
At 01:33 AM 2/7/2004, Thomas Grill wrote:
Hi Julius, could this be a problem related to flext usage?
best greetings, Thomas
----- Original Message ----- From: "Julius Smith" jos@ccrma.stanford.edu To: msp@ucsd.edu Cc: "d.lj" jdl@xdv.org; "pd-dev" pd-dev@iem.kug.ac.at Sent: Saturday, February 07, 2004 9:33 AM Subject: Re: [PD-dev] Help search; standard external installation paths
Hi Miller,
Hmmm, it sounds like I must have a special problem of some kind. I'll go after it on my machine (a Red Hat 9 Linux system) and report
back.
Thanks, Julius
At 05:12 PM 2/6/2004, Miller Puckette wrote:
Hi Julius,
I can't find where the tilde is getting deleted... I just got help
for
the
extern "fiddle~" which picked up "help-fiddle~.pd" correctly. So I
have
no idea what's going on here...
cheers Miller
On Tue, Jan 27, 2004 at 11:53:04AM -0800, Julius Smith wrote:
Thanks for the help. Is there a recommended way to access this
function
[class_sethelpsymbol(t_class *c, t_symbol *s)] via flext?
It still seems to me that the default behavior (removing the
tilde) is
incorrect.
Julius
At 02:48 AM 1/27/2004, d.lj wrote:
[Julius Smith]->[[PD-dev] Help search; standard external
installation...
|Dear pd-dev, | |When pd searches for a help file in response to "right-click
Help"
on
some |external object, the '~' is removed from the sought filename.
This
seems
|incorrect since it prevents "signal-based" and "message-based"
objects
from |having the same root name. I would think the '~' should be fundamentally a |part of the module's name. | |My current workaround is to install a symbolic link from
"help-name~.pd"
to |"help-name.pd" in my doc dir for externals, which seems rather
ugly.
the help file can be set:
http://iem.kug.ac.at/pd/externals-HOWTO/node9.html#SECTION0009210000000
00000000
-- X d U . o R
G
GPG-key at http://xdv.org/~jdl/jdl.pub.asc
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Julius O. Smith III jos@ccrma.stanford.edu Assoc. Prof. of Music and (by courtesy) Electrical Engineering CCRMA, Stanford University http://www-ccrma.stanford.edu/~jos/
-
d.lj -
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Julius Smith -
Larry Troxler -
Miller Puckette -
Thomas Grill