[PD] counter + list of objects

[marius schebella]

I think with pd-extended many decisions just happened. the goal was to 
get a lot of libraries included to make installation and distribution of 
an "extended" version of pd easy - not only for new users.

In the case of counter, there are at least two objectclasses, the one 
from cyclone (cloning the c74 counter) and the iem counter. and probably 
more abstractions.

If there will ever be something like a standard library of additional 
objects (and/or abstractions) I would suggest to go with the max 
compatible version.

I have a wish which I think is related to this discussion: more higher 
level pd patches and better communication of existing patches. (ok, 
that's 2 wishes.)

marius.

Andy Farnell wrote:
> 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
> 
>