[PD] Do these sound familiar??

guenter geiger geiger at xdv.org
Tue Apr 22 13:05:21 CEST 2003


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
> 	   \
> 	    \
> 	     \
>
>
> _______________________________________________
> PD-list mailing list
> PD-list at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
>





More information about the Pd-list mailing list