I cc'ed the list since I think this is a worthwhile discussion.
On Mon, 21 Apr 2003, Michael McGonagle wrote:
There is already an object called 'accum' in cyclone and Max/MSP. It sounds like they do similar things.
I did look it up in the database (linked below), but it did not show references to either of these libraries as having an 'accum' external. There was one in GEM, but I did not look at it yet...
I did look at the source to cyclone's 'accum', and it does not present the same "abilities" as mine.
I hope you didn't interpret my email as saying that you shouldn't release your objects. I was just listing off similar objects. The only thing I ask is that you try to avoid name clashes with existing Pd objects and Max/MSP objects. The GEM vs. maxlib scale for example, or different [counter] objs are a major pain.
There is quantize~ in zexy.
After looking at the source for this, it looks like this will quantize a signal to a particular bit level, while mine quantizes to an arbitrary 'grid' (quantization points are multiples of this value). The zexy external also operates at audio rate, while mine is more intended to be used as a "controller" (it could be implemented as a tilde external, but is currently not).
My two bits on this: in the interest of naming coherence, I think that same-named objects for audio- and control-rate, [quantize~] and [quantize] for example, should be as similar as possible.
I have used the database in the past, but it does seem to have some serious holes there (as presented by me search of 'accum'). Some libraries seem to be large "catch-all" classes of externals, that after looking at them, did not seem to contain useful (to me at least) externals.
Yes, the PDB is out-of-date. Its user-editable now, add your objects! I need to add mine, but they are still quite new and untested.
While I wonder if there is a better solution to this, what is that solution? Should all externals be "reclassified" into various catagories by functionality, and then re-packaged??? Having these larger, "catch-all" types of libraries (IMHO) only leads to the developement of more externals. As each library becomes larger, it becomes less likely that a new user will look thru them instead of just developing their own externals. I am assuming that most PD users are also C programmers. (I do appreciate the easy C API that PD presents).
This is happening somewhat with the SourceForge project. Basically, any external that doesn't have any lib dependencies is added to the pd-externals pacakge. There there are pd-osc, pd-flext, pd-zexy, and maybe some other packages.
I think the way to solve the problem of tracking the new objects down is to have help patches that list all related objects on the page as well. Also, a hierarchical navigatible structure would be great. The VASP help patches are a great example.
It seems to me that most people who are working with PD are not really interested in making a "prepackaged" program for others, but more a tool that they can use for their own purposes.
As for Pd users mostly being programmers, that may be true, but I a one of the people working on making Pd accessible to the non-programmer masses. I think the whole Pd community has a lot to gain from expanding the user base.
.hc
zen
\
\
\[D[D[D[D
Yes, what we need is not more externals but better organization of those who are there. This was the goal of the CVS and of the PDB.
Everyone who has tried to give an overview of what is possible with pd to users probably encountered the same problem.
Everything is possible, but it becomes impossible to find the way to do it (Especially for new users).
Everytime someone announces a new external, I look at it in two ways. On one side it is good to have more functionality, on the other side .. duplicated functionality, more trees in the jungle, ... and the question if the same thing could have been written as an abstraction.
The case of Michael here shows our dilemma. Even for developers, for people who know pd well it has gotten impossible to have an overview of what is there.
Thats why the work that is done by .hc and all the others to make the pd resources more accesible is that important.
.. and there is so much left to be done still
Guenter
On Mon, 21 Apr 2003, Hans-Christoph Steiner wrote:
I cc'ed the list since I think this is a worthwhile discussion.
On Mon, 21 Apr 2003, Michael McGonagle wrote:
There is already an object called 'accum' in cyclone and Max/MSP. It sounds like they do similar things.
I did look it up in the database (linked below), but it did not show references to either of these libraries as having an 'accum' external. There was one in GEM, but I did not look at it yet...
I did look at the source to cyclone's 'accum', and it does not present the same "abilities" as mine.
I hope you didn't interpret my email as saying that you shouldn't release your objects. I was just listing off similar objects. The only thing I ask is that you try to avoid name clashes with existing Pd objects and Max/MSP objects. The GEM vs. maxlib scale for example, or different [counter] objs are a major pain.
There is quantize~ in zexy.
After looking at the source for this, it looks like this will quantize a signal to a particular bit level, while mine quantizes to an arbitrary 'grid' (quantization points are multiples of this value). The zexy external also operates at audio rate, while mine is more intended to be used as a "controller" (it could be implemented as a tilde external, but is currently not).
My two bits on this: in the interest of naming coherence, I think that same-named objects for audio- and control-rate, [quantize~] and [quantize] for example, should be as similar as possible.
I have used the database in the past, but it does seem to have some serious holes there (as presented by me search of 'accum'). Some libraries seem to be large "catch-all" classes of externals, that after looking at them, did not seem to contain useful (to me at least) externals.
Yes, the PDB is out-of-date. Its user-editable now, add your objects! I need to add mine, but they are still quite new and untested.
While I wonder if there is a better solution to this, what is that solution? Should all externals be "reclassified" into various catagories by functionality, and then re-packaged??? Having these larger, "catch-all" types of libraries (IMHO) only leads to the developement of more externals. As each library becomes larger, it becomes less likely that a new user will look thru them instead of just developing their own externals. I am assuming that most PD users are also C programmers. (I do appreciate the easy C API that PD presents).
This is happening somewhat with the SourceForge project. Basically, any external that doesn't have any lib dependencies is added to the pd-externals pacakge. There there are pd-osc, pd-flext, pd-zexy, and maybe some other packages.
I think the way to solve the problem of tracking the new objects down is to have help patches that list all related objects on the page as well. Also, a hierarchical navigatible structure would be great. The VASP help patches are a great example.
It seems to me that most people who are working with PD are not really interested in making a "prepackaged" program for others, but more a tool that they can use for their own purposes.
As for Pd users mostly being programmers, that may be true, but I a one of the people working on making Pd accessible to the non-programmer masses. I think the whole Pd community has a lot to gain from expanding the user base.
.hc
zen
\[D[D[D[D
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
-
guenter geiger -
Hans-Christoph Steiner