[PD] counter + list of objects

Sun Jan 13 21:18:17 CET 2008

Its a good point Damien. And to expand on it let's say it's
not a personality type but a mode of working or a level of
comfort. We all do it in one way or another, indeed we must
to accomplish anything.

We could take this to any level and find the same.

Going down one level we can say there are people who only work
by plugging externals together. We might say they "aren't really
interested in programming" because they never use a C compiler
to write an object and just want to use other peoples super-rad
pre-made components.

Or let's take it up a level. Some people would never dirty their
hands with Max or Pd and only want to use a sequencer with VST
plugins.  

Or let's go down one level deeper, and note there are programmers
who are content to cut and paste DSP code from someone elses
super-rad pre-built algorithm and never get down and dirty with
the equations.

Wherever you go it's Russian dolls, there's wheels within wheels,
a great tower of abstraction in which you will find most people 
happiest at some level of granularity. Assuming they're working
with open components, then if they're challenged by a problem that
can't be solved at their comfort level they might venture down
one level. Other times they will take things easy in order to 
construct something of scale and use a collection of pre-built
components without caring how they work inside. All of us who 
write code use libraries of some kind.

One problem, a psychological pattern if you like, is a false belief
that some task can only be accomplished by going to another level.
Or, in the same way, a  belief that it is appropriate to solve
something at the wrong level. 

More often that not this can be identified as a lack of 
knowledge. For example, many times I've thought "why isn't 
component X a standard Pd object?", only to realise later that it's
a simple idiom using as few as two or three core objects. Likewise,
I've had musicians or sound guys say to me "How do you make
sound Y, what's the plugin to use?", and I say there isn't a plugin
that does that, but if you put a distortion and gate into the 
side chain of a compressor....

The higher up the tower of abstraction you go the more you meet an
attitude that seems like laziness on the face of it, but is actually
a  belief that there's a one to one correspondence between
each task and an available function or object, rather than it being
appropriate to do some work at the current level. You get the idea 
you are missing something, when in fact it's right in front of you.
I once spent days trying to find the right OSC library (imho Steve
Harris liblo is the good one btw ;) not realising that if I just read
the OSC spec I could do what I needed with simple sockets.

The lower down the tower you go the more you meet a reciprocal
belief (which I know I am guilty of sometimes), that absolutely 
everything must be built from first principles using the most atomic
components. At some point using the sockets became too unweildy, so
I took the sensible option of using a component that someone else
had put the hard work into getting right.

Neither of these "working level mismatches" are good, at least
they're not optimally productive.

Maybe there should be a common [counter] object in Pd, maybe not. 
I happen to believe there should not be, because the[f]X[+ 1] counter
idiom is appropriate to the level of working in Pd. I also take Franks
view that [counter] name is too heavily overloaded so it does more harm
than good to try and disambiguate it and settle on a standard behaviour.

Pd-extended solves the problem one way. It provides a vast wealth of 
ready meals. Want a compressor or a monophonic TB303 synth? Just
search through pd-ext. 

An alternative, and what has been missing until the pd-wiki took off,
is a library of design patterns and programming idioms. The help files
and Millers book go some way towards this, but I don't think either are
appropriate for _beginners_ to  **work at the level Pd is designed for**.
Having said that I'm not sure how to do it better, but I am trying
with tutorials and the like. The problem with knowledge bases and
knowledge search in general is that as a beginner you often don't know
what it is you're looking for, until someone gives a concept you 
are grasping for a name and context.

A final point is that Pd has the best in-built facility for self 
instruction of any software I know. It has abstractions that can be 
inspected immediately. Abstraction should be *number one* on any Pd
teaching syllabus (after covering the basics of dataflow). 

However, coming to Pd as an experienced programmer I had trouble
with abstractions, got bitten and learned to avoid them. I think
there is still some room for improvement in the way Pd handles search
paths and user library building. 

We've been though it before and we all know the issues and that 
there's no easy solution that is backwards compatible too. 

One brain fart I had was that we should make use of the two letter
prefix [my thing], built right in to the Vanilla core as a special
kind of abstraction that is a "local user library space". So,
basically [my counter] is a normal abstraction (not a subpatch)
that lives in (is hard wired to be loaded from and saved to) a
special directory.

I say this because as I learned to use abstraction properly (so
as not to trash dozens of patches by changing a key abstraction) I
developed the discipline to name all abstractions [myabs-something]
so not to stomp on others. This is one of the few things that it
might be kind and helpful to "force on new users for their own good",
without depriving them of the freedom to use "bare abstractions" of
course.

Well, I will be a coward and end saying there's no right level to
work on. We are lucky to have so many options that come with open source
and open attitudes. Knowing that you can take things apart to see how
they work and change them is fundamental, not just to Pd but to 
programming, Art and Science generally. I recognise the strong sentiment
that its good to encourage curiosity, to see how things are done rather than
accept a pre-packaged solution, but some people choose not to work on
that level and they are no less programmers for it. The moto of Perl
TMTOWTDI (there's more than one way to do it) could be shouted a bit
louder around here. One of the most crippling beliefs for a new user
to aquire is that there is some definitive, correct and approved way
to do something. Sometimes there is, but that comes with experience.

\ramble

Andy

On Sun, 13 Jan 2008 18:40:31 +0100
Damian Stewart <damian at frey.co.nz> wrote:

> Luke Iannini (pd) wrote:
> > I know Pd-E does this to be as easy as possible to set up for new
> > users, but at the same time perhaps it is best that a new user sticks
> > with the vanilla objects anyways, and if they're really interested in
> > more objects, they can learn how to use the directory prefixes or
> 
> several people i've talked to are used to using Max this way:
> 
> 1) buy Max
> 2) download awesome super rad pre-made patch
> 3) open awesome super rad pre-made patch + be happy
> 
> i tell them, use pd, it's free!
> 
> so they
> 
> 1) download Pd
> 2) download awesome super rad pre-made patch
> 3) open awesome super rad pre-made patch and scratch heads when it doesn't 
> work because they don't have particular externals
> 
> to ask this kind of user to 'stick with the vanilla objects' avoids the 
> fact that actually there are some (perhaps many) potential users of Pd who 
> use Pd/Max in the way i have described - ie they don't actually want to 
> learn to program properly, just learn enough to string other people's 
> pre-made super rad awesome patches together.
> 
> (incidentally this seems to be how a lot of people learn to code in the 
> days of open sourcey art code on the Intertubes - for example with 
> Processing, i've lost count of the number of times i've helped people out 
> who say they don't really know how to code, they just copy and paste other 
> people's (usually already quite complex) stuff and then fiddle until it works.)
> 
> -- 
> damian stewart | +351 967 797 263 | damian at frey.co.nz
> frey | live art with machines | http://www.frey.co.nz
> 
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-- 
Use the source