[PD] Do these sound familiar??

[Hans-Christoph Steiner]

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
	   \
	    \
	     \