[PD] pdmtl abstractions questions and comments

[Frank Barknecht]

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

> >If someone else does an abstraction collection for lists, I'd say,
> >"list_" or "list." are two other good choices.
> 
> So far, Max seems to be using ".", for example "jit."; because of this, 
> I've used the "." prefix but for "lti." classes; actually I also used it 
> for some PureUnity classes, initially like "f." "~." "#." to mean float's, 
> signal's, grid's, in a way that is meant to be used as [$1.hello]. I have 
> changed this to around to [hello.$1] because of pd 0.40 and of personal 
> preference.

There is a minor annoaynce with the dot for abstractions ATM because
of an unfixed bug: If you save a new abstraction that already has a
dot in its name like "list.abs", you need to add the ".pd" extension
manually, otherwise Pd will save it as "list.abs" instead of
"list.abs.pd". This is not a problem with "list-abs" which gets the
suffix added automatically by Pd.

> >Where directory prefixes shine however is for making packages of
> >externals and abstractions. Pd-extended is the prime example: It can
> >ship all five [counter] objects, which would be impossible without
> >subdirectories for each collection.
> 
> Edit the five source files, changing the name in it for something else. Is 
> that so impossible? It might not be pretty, but I wouldn't call it 
> "impossible".

Well, but then you wouldn't have five objects named [counter]
anymore. And of course there is the social problem: How is it decided,
which counter should keep its name? And that is actually what I meant
with this: 

> >All this to me seems to kind of pervert what Guenther Geiger actually 
> >intended when suggesting directory prefixes and initiating the 
> >CVS-repository.

IIRC one motive to start the CVS was to get rid of objects that do
slightly different things but have the same name (like the [counter]s)
by first collecting them all in one place (Sourceforge), see what's
duplicated and/or conflicting, and then decide on the one "real"
counter - possibly keeping the four others with different names. 

Unfortunatly we didn't get further with developing an infrastructure
to decide things like that.

> Actually, it never occurred to me that those two things were related. I 
> think that I joined pd-list shortly after the CVS created, but I don't 
> recall that anyone said (in the last five years of pd-list) that the whole 
> externals/ thingie had to do with Geiger namespaces. 

The namespace and the CVS are not related directly, I didn't want to
imply that. Geiger namespaces are just way to keep the four other
[counter]s from above available, in case someone needs them. However I
fear, that they also became a kind of excuse to not think about
developing a way to decide things like "which [counter] to keep".

> >and the "Path" window is filled with more entries than it can handle.
> 
> Apart from what the intention might have been about paths or libs 
> (libdirs), this is not a problem with Hans's work per se, it's a problem 
> in u_main.tk, and it's very possible to fix it: e.g. 
> http://artengine.ca/desiredata/gallery/pdrc_5b.gif and the same user 
> interface also exists for -path and -helppath separately.

Of course one could easily overhaul the path windows (and one has to do
it for plain Pd as well) to be able to handle more paths, but the
actual problem is: Why are there so many paths and are they all really
necessary?

> >[list-abs/list-abs] is bit-rot.
> 
> Well, i've only seen the word "bit-rot" to mean things that result from 
> not updating software to changing interfaces (I'm not counting the meaning 
> of it that has to do with physical media). Thus I don't really know what 
> you mean by [list-abs/list-abs] is bit-rot: it's not like your [list-abs] 
> has gone unmaintained for years such that the definition of pd (or what pd 
> is in practice) has changed such that is has become contextually broken or 
> outdated or irrelevant...

I meant: Using [list-abs/list-abs] instead of just [list-abs] is a
kind of bit rot, because the more people use the double or triple
prefix, the more it gets carved into (some) stones and at some point,
users will expect the [list]-abs objects with long names to be
available. Maybe that's not something to call bit rot, but it would be
rotten. ;) 

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