Hi Im new in PD. Ive been using Max/MSP and now am trying to switch to its open source alternative.. Ive had no problem with pd so far but recently i tried creating the "counter" object and I've always had the same error "couldn't create counter. I'm pretty certain the object exists in pd since i saw it in a couple of tutorials.. am i missing a special library to get this object?
also, i would very much want to see a list of objects available in pd. i haven't seen one so far, so its difficult to know what objects are installed and i can count with! thanks for your help
jonesints
Hi John,
John Cohen wrote:
Ive had no problem with pd so far but recently i tried creating the "counter" object and I've always had the same error "couldn't create counter. I'm pretty certain the object exists in pd since i saw it in a couple of tutorials.. am i missing a special library to get this object?
Well, ermm, several actually. In a way. The problem is that the namespace for [counter] is a bit polluted, meaning that there are different versions of [counter] in different libraries which do different things. I don't recall which libraries have one, so I never use any of them!
In the help files, help/2.control.examples/05.counter.pd and 06.more.counters.pd are the standard ways of counting. See also the help file for [mod].
also, i would very much want to see a list of objects available in pd. i haven't seen one so far, so its difficult to know what objects are installed and i can count with! thanks for your help
There's one for the core PD objects in help/5.reference/0.INTRO.txt Externals change from time to time, making it difficult to keep everything current. Here's a(n incomplete) list I made some time back:
http://flossmanuals.net/PureData/ListofObjects
best, d.
thanks for the quick reply Derek. ill try what you suggest instead.
john
Jonesints
On 09/01/2008, Derek Holzer derek@umatic.nl wrote:
Hi John,
John Cohen wrote:
Ive had no problem with pd so far but recently i tried creating the "counter" object and I've always had the same error "couldn't create counter. I'm pretty certain the object exists in pd since i saw it in a couple of tutorials.. am i missing a special library to get this object?
Well, ermm, several actually. In a way. The problem is that the namespace for [counter] is a bit polluted, meaning that there are different versions of [counter] in different libraries which do different things. I don't recall which libraries have one, so I never use any of them!
In the help files, help/2.control.examples/05.counter.pd and 06.more.counters.pd are the standard ways of counting. See also the help file for [mod].
also, i would very much want to see a list of objects available in pd. i haven't seen one so far, so its difficult to know what objects are installed and i can count with! thanks for your help
There's one for the core PD objects in help/5.reference/0.INTRO.txt Externals change from time to time, making it difficult to keep everything current. Here's a(n incomplete) list I made some time back:
http://flossmanuals.net/PureData/ListofObjects
best, d.
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 54: "Do something sudden, destructive and unpredictable"
for a long time i've been an advocate of the [f ]x[+ 1] method of counting in pd cos it's a good basic introduction to hot and cold inlets and basic object joining,
but really, isn't it a bit silly that pd doesn't have a native counter object?
On Thu, 2008-01-10 at 02:27 +0900, hard off wrote:
but really, isn't it a bit silly that pd doesn't have a native counter object?
save
[inlet] | [f ]X[+ 1] | [outlet]
to <pd-path>/extra/counter.pd and you have your native object.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Wed, 9 Jan 2008, Roman Haefeli wrote:
On Thu, 2008-01-10 at 02:27 +0900, hard off wrote:
but really, isn't it a bit silly that pd doesn't have a native counter object?
to <pd-path>/extra/counter.pd and you have your native object.
No, no, he means native as in something approved by the holy church. And he isn't looking for a counter class, he's just trying to complain about the lack of it in some pd distro.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
I just want to mention that a counter object does more than just adding numbers... marius.
Roman Haefeli wrote:
On Thu, 2008-01-10 at 02:27 +0900, hard off wrote:
but really, isn't it a bit silly that pd doesn't have a native counter object?
save
[inlet] | [f ]X[+ 1] | [outlet]
to <pd-path>/extra/counter.pd and you have your native object.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
marius schebella wrote:
Roman Haefeli wrote:
On Thu, 2008-01-10 at 02:27 +0900, hard off wrote:
but really, isn't it a bit silly that pd doesn't have a native
counter object?
save
I just want to mention that a counter object does more than just adding numbers...
if it does, than afaik the _only_ language that has a "counter" built-in is max/msp. which makes me think that it is not so immensily useful as one would think, and Pd is probably right by not having a counter of it's own. (which, btw, coinicides nicely with my opinion anyhow...)
fgmasdr. IOhannes
On Thu, 10 Jan 2008, IOhannes m zmoelnig wrote:
if it does, than afaik the _only_ language that has a "counter" built-in is max/msp.
10 FOR X=1 TO 100 20 PRINT "WHAT ABOUT BASIC?" 30 NEXT X
(1..100).each {|x| puts "and then what about Ruby?" }
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
On Thu, 10 Jan 2008, IOhannes m zmoelnig wrote:
if it does, than afaik the _only_ language that has a "counter" built-in is max/msp.
10 FOR X=1 TO 100 20 PRINT "WHAT ABOUT BASIC?" 30 NEXT X
this is not a built-in counter, this is how you would write a simple counter in basic. apart from that, it does not fulfil the marius' requirement of doing "more than just adding numbers." (true, it does print out something in each iteration; but then, a counter that does not do anything but increment an accumulator would be of _very_ limited use (--> HQ9+)
(1..100).each {|x| puts "and then what about Ruby?" }
same as above.
gmasdr IOhannes
On Fri, 11 Jan 2008, IOhannes m zmoelnig wrote:
10 FOR X=1 TO 100 20 PRINT "WHAT ABOUT BASIC?" 30 NEXT X
this is not a built-in counter, this is how you would write a simple counter in basic.
Frankly, I don't understand the difference. I mean FOR/NEXT, I don't mean the exact code I wrote above.
apart from that, it does not fulfil the marius' requirement of doing "more than just adding numbers."
I don't care, it's not what I was replying to. I was only replying to the part of the mail that I have quoted. You seem to be disregarding that.
iteration; but then, a counter that does not do anything but increment an accumulator would be of _very_ limited use
You don't need to assume that I mean only the above three lines of BASIC code, instead of FOR/NEXT.
(--> HQ9+)
I don't speak that language.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Quoting Mathieu Bouchard matju@artengine.ca:
On Fri, 11 Jan 2008, IOhannes m zmoelnig wrote:
10 FOR X=1 TO 100 20 PRINT "WHAT ABOUT BASIC?" 30 NEXT X
this is not a built-in counter, this is how you would write a
simple counter in basic.Frankly, I don't understand the difference. I mean FOR/NEXT, I don't mean the exact code I wrote above.
right. in Pd this would be
[100( | [until] | [print]
period.
apart from that, it does not fulfil the marius' requirement of
doing "more than just adding numbers."I don't care, it's not what I was replying to. I was only replying to the part of the mail that I have quoted. You seem to be disregarding that.
indeed. but "so what"?
sorry if i was inaccurate about what you replied to, but the original
question was about having a counter that does "more than just adding
numbers".
if somebody asks about strings, i would consider the following anser
inadequate:
[this is a string( | [print]
iteration; but then, a counter that does not do anything but
increment an accumulator would be of _very_ limited useYou don't need to assume that I mean only the above three lines of BASIC code, instead of FOR/NEXT.
i have not questioned this. i only tried to stay on safe ground...
(--> HQ9+)
I don't speak that language.
it's a pity, as it is a very nice language (though not turing complete).
i have written a very simplistic implementation in Pd:
http://puredata.info/Members/zmoelnig/hq9
(i think the standalone 99-bottles-of-beer is broken; but it is fixed
in the HQ9+ interpreter)
mfga.sdr IOhannes
This message was sent using IMP, the Internet Messaging Program.
did I say something wrong? there are several counter objects. but none built into Pd. and yes, I was refering to the max counter-objectclass, because that is how the thread started. the max version can count up and down (and also up&down), has optional startig and end position and can be reset, it also has an outlet that tells you when you reached the maximum number and also when it reached the minimum/starts recounting. the closest pd version is from cyclone. and counter *is* useful. marius.
IOhannes m zmoelnig wrote:
marius schebella wrote:
Roman Haefeli wrote:
On Thu, 2008-01-10 at 02:27 +0900, hard off wrote:
but really, isn't it a bit silly that pd doesn't have a native
counter object?
save
I just want to mention that a counter object does more than just adding numbers...
if it does, than afaik the _only_ language that has a "counter" built-in is max/msp. which makes me think that it is not so immensily useful as one would think, and Pd is probably right by not having a counter of it's own. (which, btw, coinicides nicely with my opinion anyhow...)
fgmasdr. IOhannes
On Fri, 2008-01-11 at 16:52 -0500, marius schebella wrote:
did I say something wrong? there are several counter objects. but none built into Pd. and yes, I was refering to the max counter-objectclass, because that is how the thread started. the max version can count up and down (and also up&down), has optional startig and end position and can be reset, it also has an outlet that tells you when you reached the maximum number and also when it reached the minimum/starts recounting. the closest pd version is from cyclone. and counter *is* useful. marius.
still, this could be implemented easily as an abstraction. that is why i still think, that there is no need to have it as a built-in object (which is not going to happen anyway, i assume, so we can actually bury this thread).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Quoting marius schebella marius.schebella@gmail.com:
did I say something wrong?
no
there are several counter objects. but none built into Pd. and yes, I was refering to the max counter-objectclass, because that is how the thread started. the max version can count up and down (and also up&down), has optional startig and end position and can be reset, it also has an outlet that tells you when you reached the maximum number and also when it reached the minimum/starts recounting. the closest pd version is from cyclone. and counter *is* useful.
i do not doubt that it is useful.
i only tried to say that i don't see a reason to include it into the
core of Pd, as Pd already gives you the possibility to write a
[counter] of your personal taste.
it is not a feature that is "missing" (like inheritance).
mfgads.r IOhannes
This message was sent using IMP, the Internet Messaging Program.
ok, then it was a misunderstanding, I am also not saying that is has to be in the core of pd. (is there an official policy that objectclasses which can be created as abstractions should not be included as c objectclass?...) but now, when I think about this... why is there now pd-featured abstraction list? counter would be an object that should be included in "standard abstractions folder". or is everybody supposed to create his own version of useful abstractions over and over again? marius.
zmoelnig@iem.at wrote:
Quoting marius schebella marius.schebella@gmail.com:
did I say something wrong?
no
there are several counter objects. but none built into Pd. and yes, I was refering to the max counter-objectclass, because that is how the thread started. the max version can count up and down (and also up&down), has optional startig and end position and can be reset, it also has an outlet that tells you when you reached the maximum number and also when it reached the minimum/starts recounting. the closest pd version is from cyclone. and counter *is* useful.
i do not doubt that it is useful. i only tried to say that i don't see a reason to include it into the
core of Pd, as Pd already gives you the possibility to write a
[counter] of your personal taste. it is not a feature that is "missing" (like inheritance).mfgads.r IOhannes
This message was sent using IMP, the Internet Messaging Program.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 2008-01-11 at 19:01 -0500, marius schebella wrote:
ok, then it was a misunderstanding, I am also not saying that is has to be in the core of pd. (is there an official policy that objectclasses which can be created as abstractions should not be included as c objectclass?...)
i don't know, but to me it seems, that miller follows such kind of a policy. you will hardly find any built-in classes, that could be easily substituted by abstractions made of other classes and if so, they are there because of historical reasons (is that correct?)
but now, when I think about this... why is there now pd-featured abstraction list?
yeah, why? i think that would be a nice thing to have.
counter would be an object that should be included in "standard abstractions folder".
i think the problem is to find a universal counter object. i usually find it easier to quickly hack a counter for the special task i need it for than figuring out if a certain existing counter class fits my needs (to realize afterwards, that it isn't exactly what i was looking for).
or is everybody supposed to create his own version of useful abstractions over and over again?
no, you create it once and you can reuse it over and over again.
btw: it's exactly to goal of pdmtl-abs to collect abstractions, that could be of general use. if you miss a counter class with a certain behaviour, please feel free to add it (or ask someone to implement it for you).
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
yes, the pdmtl-abs need to get better promoted. they are not widely known outside the pd montreal community. and afaik there is not reason not to include them in pd-extended. they have a fancy patching style, but ok... is pdmtl in a path that is searched by pd by default? marius (yaotm*).
- yet another off thread message...
btw: it's exactly to goal of pdmtl-abs to collect abstractions, that could be of general use. if you miss a counter class with a certain behaviour, please feel free to add it (or ask someone to implement it for you).
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, marius schebella hat gesagt: // marius schebella wrote:
yes, the pdmtl-abs need to get better promoted. they are not widely known outside the pd montreal community. and afaik there is not reason not to include them in pd-extended. they have a fancy patching style, but ok...
In general I think it's tricky if abstractions meant to be standard abstractions for Pd use externals themselves.
Ciao
Frank Barknecht _ ______footils.org__
On Sat, 2008-01-12 at 08:44 +0100, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
yes, the pdmtl-abs need to get better promoted. they are not widely known outside the pd montreal community. and afaik there is not reason not to include them in pd-extended. they have a fancy patching style, but ok...
In general I think it's tricky if abstractions meant to be standard abstractions for Pd use externals themselves.
on one hand i agree with you, since a collection purely based on internals would be a nice thing to have as well (i even would prefer such a collection). on the other hand, i'd be interested to hear from you, what you mean by "it's tricky". what is wrong with declaring that pdmtl-abs are meant to provide a set of higher level abstractions based on pd-extended? the depencencies are clearly declared and are available for all platforms.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Sat, 2008-01-12 at 08:44 +0100, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
yes, the pdmtl-abs need to get better promoted. they are not widely known outside the pd montreal community. and afaik there is not reason not to include them in pd-extended. they have a fancy patching style, but ok...
In general I think it's tricky if abstractions meant to be standard abstractions for Pd use externals themselves.
on one hand i agree with you, since a collection purely based on internals would be a nice thing to have as well (i even would prefer such a collection). on the other hand, i'd be interested to hear from you, what you mean by "it's tricky". what is wrong with declaring that pdmtl-abs are meant to provide a set of higher level abstractions based on pd-extended? the depencencies are clearly declared and are available for all platforms.
Abstractions for pd-extended could of course use any external included there[1], but I meant standard abstractions for (any distribution of) Pd.
[1] But note that even abstractions for pd-extended need to take care of nameclashes, i.e. use declare/import, use directory prefixes etc. Many abstraction collections are sloppy when handling this. (Even abstractions by pd-extended advocates can forget to always fully specify the full names of abstractions with import or a prefix. I don't want to point fingers, but to illustrate what I mean: In the "mapping" library max_n.pd uses [maximum] from Cyclone undeclared, disjoin.pd uses [float_argument] from purepd undeclared etc.)
Ciao
Frank Barknecht _ ______footils.org__
On Jan 12, 2008 1:18 PM, Frank Barknecht fbar@footils.org wrote:
Many abstraction collections are sloppy when handling this. (Even abstractions by pd-extended advocates can forget to always fully specify the full names of abstractions with import or a prefix. I don't want to point fingers, but to illustrate what I mean: In the "mapping" library max_n.pd uses [maximum] from Cyclone undeclared, disjoin.pd uses [float_argument] from purepd undeclared etc.)
The abstraction collections are sloppy because they can be, I think. Since Pd-E, by default, loads nearly everything into the global namespace, one can easily be lazy when developing abstractions.
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 [declare]. Python is the only language I have experience with that has a wonderful namespace system, and I think it works greatly to its advantage.
So, on that note, I think it would be best to choose some truly essential objects as the beginning of a base (global by default) library, which should be periodically updated as new objects outgrow their libraries in popularity. A nice counter would be a good start : ).
Just as a note, it would be pretty easy to do a find/replace on the entire pd-extended tree for those objects with unique names.
Finally, every time we talk about things that I would like to be helping to fix, I itch for Subversion. I've said it before, but I have continually put off getting any comfort with CVS because I always think the move to SVN is a couple weeks away : ). Not to mention, Pd is the only project I know of that still uses CVS, so learning it would be very expensive to my brainspace.
And finally finally, has the [declare]/libdir/etc. practice been truly sorted out? A nice wiki entry describing correct usage would be a huge help, if so.
Cheers Luke
(oh, one more thing... it would be cool to have an auto-generated "meta" file that /is/ added to the global namespace, so i could type [mapping], and opening it shows a list of all patches in the [mapping] dir. And if, in the object help files, a special comment was added with a description, that could also be lifted out and put in the metafile next to the object. This would be analogous to Python's docstring/help(fxn) system.)
Hi Luke,
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 [declare].
I strongly disagree. Most beginners want to play with high-level objects that do a lot of the programming for them, rather than dive deep into data flow & etc. Do we give them what they want, or do we do what's "good for them"? I think beginners should have access to the most amount of functions they can without any bullshit. They can learn all the super-geek stuff later on, when they want to optimize the performance of PD or customize behaviors. Let them get busy making noise and pictures first, though! Otherwise they get frustrated and run off the get a crack of Max/MSP or something.
My two drachmas, d.
On Jan 13, 2008 5:24 AM, Derek Holzer derek@umatic.nl wrote:
I strongly disagree. Most beginners want to play with high-level objects that do a lot of the programming for them, rather than dive deep into data flow & etc. Do we give them what they want, or do we do what's "good for them"? I think beginners should have access to the most amount of functions they can without any bullshit. They can learn all the super-geek stuff later on, when they want to optimize the performance of PD or customize behaviors. Let them get busy making noise and pictures first, though! Otherwise they get frustrated and run off the get a crack of Max/MSP or something.
Well, I quite agree with you, but I don't agree that having to say [synth/megasaw] qualifies as super-geek bullshit... if they've discovered the object, and the object says to call it that way (this would have to be true, of course), I don't think we're pushing the brain-barriers of the beginner too far. If anything, the prefix serves to document and organize the object to reduce confusion. Especially if they say "oh, I wonder what else is in this 'synth' package", it's encouraging exploration.
Cheers Luke
Hallo, Derek Holzer hat gesagt: // Derek Holzer 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 [declare].
I strongly disagree. Most beginners want to play with high-level objects that do a lot of the programming for them, rather than dive deep into data flow & etc.
Well, yes and no: beginners may want a counter object, but they won't like it if they find out that there are four of them, all incompatible.
Ciao
Frank Barknecht _ ______footils.org__
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:
- buy Max
- download awesome super rad pre-made patch
- open awesome super rad pre-made patch + be happy
i tell them, use pd, it's free!
so they
- download Pd
- download awesome super rad pre-made patch
- 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.)
Hi all,
Damian Stewart wrote:
- download Pd
- download awesome super rad pre-made patch
- open awesome super rad pre-made patch and scratch heads when it doesn't
work because they don't have particular externals
My point precisely. Or, as someone told me their Dutch media-arts instructor said, "Using PD is like living in Communist Russia" [compared to Max/MSP, I presume]. To which I might append "Using only *vanilla* PD is like living in Communist Russia." PD-Extended was conceived as a way to have things "just work"[tm], especially for people who are brand-new to PD or to programming in general. Why go fooling with that out of some purist notions about core PD objects vs "tainted" externals? And why ask them to grapple with such arcane concepts as "namespaces" when the external objects can simply just be there, and they can get busy playing?
best, d.
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
And why ask them to grapple with such arcane concepts as "namespaces" when the external objects can simply just be there, and they can get busy playing?
Because they can't. You cannot and probably never will be able to load two different objects called the same, like [counter]. That's not gonna fly. So most def you need some kind of different name for each, and voila, the rocket is out in namespace. And the larger the number of available objectclasses, the higher the risk of such a nameclash. Actually Max/MSP has exactly the same problem. It just comes with some more names built-in.
Ciao
Frank Barknecht _ ______footils.org__
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@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:
- buy Max
- download awesome super rad pre-made patch
- open awesome super rad pre-made patch + be happy
i tell them, use pd, it's free!
so they
- download Pd
- download awesome super rad pre-made patch
- 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@frey.co.nz frey | live art with machines | http://www.frey.co.nz
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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:
- buy Max
- download awesome super rad pre-made patch
- open awesome super rad pre-made patch + be happy
i tell them, use pd, it's free!
so they
- download Pd
- download awesome super rad pre-made patch
- 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@frey.co.nz frey | live art with machines | http://www.frey.co.nz
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hm, I don't think this is really about trying to force new people into grappling with arcanum, or telling them "what's best", so much as it is about what is actually best for Pd as a community, the benefits of which will also touch new people.
If we want to encourage a large library of these premade objects that are so useful to everyone, it's rather essential that they can be used without causing a conflict, which is rather inevitable if the number of abstractions and externals in Pd-E continues to grow without making any changes.
If given the choice between A) giving an extra 30 seconds of instruction (or 0, if everything is executed properly) to tell a user to use [bloscs/saw~] rather than [saw~], and B), explaining to a user that [saw~] is used in many libraries so it is no longer the [saw~] they thought it was, and this new one has an entirely different interface...
Users already have to use the help-browser to find new objects, and again, if the help patches for said objects used the namespace prefix when demonstrating usage, the user would not be troubled any differently than they are now.
And also again, with the way things are, if the user discovered an object like [saw~] in an abstraction, and wanted to find the rest of these handy [bl-waveforms], they'd have to dig through the help-browser. But if they saw [bloscs/saw~], they'd know where to go.
Even in Cubase, my VST plugins are organized like "Filter", "Modulation", "Delay", "Reverb", and by "manufacturer library" as well, like "Waldorf", "UAD-1"...
Cheers Luke
Hallo, marius schebella hat gesagt: // marius schebella wrote:
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.)
My take on wish one is exemplified in [list]-abs (and to some extent in RTClib): I designed the [list]-abs to provide a higher level interface to work with lists, that is implemented without any external so it runs on *any* distribution of Pd.
Once the interface was done, it was possible to develop alternate implementations of the abstractions using externals. Example: [list-drip] is a purepd abstraction, but personally I use a version, which has [drip] hidden inside and is a bit faster. Another example: [list-len] is available as a version for older Pds without [list length] as well, the current version however started to use [list length] as soon as that found its way into Pd. The side effect is, that I don't need to hunt down every patch that uses [list-len] and change it for each Pd version. And when Miller decides to include some [list nth] method, I'm ready to use that by just changing the [list-idx] abstraction in one place.
Another example is in RTClib, which uses a variant or [urn]. As there are two incompatible [urn]s I wrote a third one, [urne], as a purepd abstraction. Still one could use one of the [urn]s of maxlib or zexy inside urne.pd instead. But I don't force on anybody which [urn] to use. I don't like forcing people and I don't like being forced.
Morale of story: In my belief, abstraction collections that (as default) only rely on core objects make life much easier for just about everyone, beginners and advanced users.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Morale of story: In my belief, abstraction collections that (as default) only rely on core objects make life much easier for just about everyone, beginners and advanced users.
you are right. but then you still have the problem that the abstraction collections are not shipped with core pd. so what exactly is the advantage in terms of compatibility? your patch would still be useless without the missing abstraction objects. marius.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
Morale of story: In my belief, abstraction collections that (as default) only rely on core objects make life much easier for just about everyone, beginners and advanced users.
you are right. but then you still have the problem that the abstraction collections are not shipped with core pd. so what exactly is the advantage in terms of compatibility? your patch would still be useless without the missing abstraction objects.
True, but I could bundle the abstractions with the patch easily, as nothing needs to be compiled.
Ciao
Frank Barknecht _ ______footils.org__
On Mon, 14 Jan 2008 17:15:09 +0100 Frank Barknecht fbar@footils.org wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
Morale of story: In my belief, abstraction collections that (as default) only rely on core objects make life much easier for just about everyone, beginners and advanced users.
you are right. but then you still have the problem that the abstraction collections are not shipped with core pd. so what exactly is the advantage in terms of compatibility? your patch would still be useless without the missing abstraction objects.
True, but I could bundle the abstractions with the patch easily, as nothing needs to be compiled.
That's fine for experienced users who can search for used abstractions and zip it all up, but what Pd currently lacks is any notion of "export project" which does all that work for you.
This is why I still try to put everything into a single vanilla file when giving patches to teach/demonstrate (rather than for my own use). I just can't yet make any sensible assumption about what abstractions the user has got (although that is changing now pd-extended is becoming more defined).
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
That's fine for experienced users who can search for used abstractions and zip it all up, but what Pd currently lacks is any notion of "export project" which does all that work for you.
True++. But anyway, you have this problem anyway, but if the abstractions you're using are only using internal objects, bundling is already much easier. (You start Pd without any "-path" set, note errors in the console, find these files and bundle them.)
Ciao
Frank Barknecht _ ______footils.org__
On Mon, 14 Jan 2008 19:59:49 +0100 Frank Barknecht fbar@footils.org wrote:
(You start Pd without any "-path" set, note errors in the console, find these files and bundle them.)
So obvious, yet so annoyingly missing from my knowledge. The time I could have saved :) Cheers Frank.
FYI: Pd-extended uses cyclone's [counter] by default, which is Max/ MSP compatible.
.hc
On Jan 9, 2008, at 12:27 PM, hard off wrote:
for a long time i've been an advocate of the [f ]x[+ 1] method of counting in pd cos it's a good basic introduction to hot and cold inlets and basic object joining,
but really, isn't it a bit silly that pd doesn't have a native
counter object?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
-
Andy Farnell -
Damian Stewart -
Derek Holzer -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
John Cohen -
Luke Iannini (pd) -
marius schebella -
Mathieu Bouchard -
Roman Haefeli -
zmoelnig＠iem.at