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