[PD] synthesizers / drums / effects ..etc

[Frank Barknecht]

Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

> On Wed, 14 Dec 2005, Frank Barknecht wrote:
> 
> > Why are you converting abstractions to subpatches? Aren't abstractions
> > much easier to reuse than having to cut and past a subpatch? At least I
> > think so.
> 
> BTW, in GridFlow, a damn lot of useful tidbits are still only subpatches 
> instead of abstractions, and there's a reason why: for some things, there 
> are so many possible variants one may possibly want, that for easily 
> reusing an abstraction you need to make a private copy and make your own 
> changes. It's possible to include a lot of variants inside one 
> abstraction by using extra inlets and args, but sometimes it would just 
> lead to 13 inlets and 42 arguments and that's... ok I'm exaggerating. But 
> still, often, I think I have to make an abstraction for a certain thing, 
> but then I'm confused about what its feature set should be and how 
> configurable it should be, and then it becomes a mess and then I delete 
> the file and go back to my subpatches...

But every subpatch lives in an "abstraction" (as in "file", not as in
"coding style") anyway. If I look for some operation that I patched
in the past for some project, then I can use many tools (find, locate,
"Search this computer") to locate it, if it's an abstraction. If it's
hidden inside another patch I have a hard time finding that
exponential scale of 5 sfsfsf lists I did months ago. "locate
interpolate | grep pd$" will lead me right to it. 

So to reuse subpatches a lot one would need to have one or more
"master patches" open all the time. IMO it's much easier to just use
one or more "master directories" for possibly useful abstractions.

And: *If* the patches already are abstractions, I really cannot
understand why they should be de-evolved into subpatches and stuffed
into a single file. This seems like a step backwards or at least
sideways. 

Subpatches have their place, they are important for example to lay out
a clear route through an algorithm. For example I often use subpatches
that only contain a *single* object just to give something a better
name for this context, like using [pd getPosition] instead of [tabread
$0-pos]. I also often start patches by laying out several empty subpatches
and connecting them: 

  [pd getPosition]
  |
  [pd addForces]
  |
  [pd convertToFrequency]

Then these are filled as I go on. 

However as soon as something needs to be reused several times, a
subpatch is not appropriate anymore except for one-off patches. This
then is the place for an abstraction.

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__