Hi Pierre,
You raise some interesting questions. I teach pd occasionally or just help newbies to get their feet wet, get off the ground or simply help with some specific projects. I will address some of the issues you raise below but note that my comments are not exhaustive nor definitive:
On Thu, Mar 18, 2010 at 4:22 PM, Pierre Massat pimassat@gmail.com wrote:
One is the documentation of the Extra objects of Pd-extended. It seems to like the help browser was designed at a time when there were very little externals. The vanilla help is well organized and easily accessible, but such is not the case for the massive bulk of externals, and this is a pity because i keep finding wonderful new objects everyday.
I think this needs a little clarification. While I concur that there are some undocumented objects, I think that you are talking about the problem of finding a suitable object for a particular task. Right?
This was party addressed in the antique version of pddp (pd documentation project), where help patches would also include hints about objects that are related in some way (protocol, functionality, alternatives etc). I guess this practice was inspired by the MaxMSP documentation.
Although such practice, if done diligently, would be very useful, it is at the same time futile as someone would have to go through loads of help patches to add similar objects that are being created constantly. Yes, this could be automated via scripts but then someone would need to add this information to scripts or a database of sorts. Maintenance.
A way of fixing this would be maybe to update the list of objects on Floss more frequently as well as revamping the structure of the Pd's help completely (don't know how easy or even feasible this would be though?).
I think that pdpedia (http://wiki.puredata.info) tried to address this issue. Recently someone suggested to get rid of it because it was not being used much. Perhaps it was not advertised enough and the resulting slim user-base did not provide much motivation to maintainers. Pdpedia addresses also (in some ways) you earlier point, that of finding *about* classes. Type "oscillator" for instance and you get hundreds of results, some pointing to various sound generators that actually fall into the category of oscillators. I think pdpedia is a great idea and is a potential spot for gathering info about as many externs as possible. Once again, the problem is in maintenance (this is why someone wanted to shut it down) because we all know that developers don't want to write documentation and we, users, composers, video artists, installation artists, students, lurkers and everyone else do not want to do it because we do not understand the developers and, in any case, we don't have time because we have deadlines in whatever we do. Right? Right. I am guilty of that, too.
[snip... sorry]
I'm saying this because i've found myself re-inventing the wheel more often than not, and it is always a bit frustrating to find out that somebody did the same thing you've been working on for weeks long time ago, and way better than you.
Well, this is where google and pure-data.info comes in handy. Search the archives, search the forums. It is very likely that if you are trying to do something that is more or less standard practice (chorus, spectral delay, granular synth) someone already did it. Probably more than one person, even, and implementations vary wildly.
Basically what a new user would need (well, at least what'd need) is a set of patches that tells him "Ok, you've seen all these commercial softwares (editors, sequencers, soft synths, vst plugins,etc.), well here's what's in their guts, and here's the basic stuff one can do with a computer in 2010."
I don't really agree with that. This is how bloat is created. And I must quote matju here: "Ready-made solutions are for ready-made problems. For everything else there is Pure data." Remember that Pd is a programming language and you cannot provide all possible solutions to everyone's taste. What I see a lot these days is that the attitude towards computing is slowly changing, especially in digital arts. A lot of people are trying to get away from read-made solutions and they are actually getting closer to the machine. They pick up MaxMSP, Pd, Python, C++, Java, Processing, Arduino and many other tools and they learn how to do stuff that the software market is not able to provide. Computers are more and more accessible to people, much cheaper than 15-20 years ago, more powerful, too, and I think that a very valid way to be creative with a computer is to learn how to speak its language. It is not for everyone though and it doesn't have to be. If I am not interested in solving problems algorithmically through programming, I will not use Pd but some other software that will help me accomplish my goals via some other means that I can understand better.
This in my view would be a great help and would boost Pd user's creativity a great deal, because they wouldn't have to re-invent (almost) everything from scratch, and they'd learn very quickly what is new and what is not. This is especially true for people who learned Pd by themselves, without taking any classes about audio programming and digital music theory.
well, the thing is that in order to even start connecting some high-level sound makers in Pd you need to have some knowledge and understanding about signal flow, especially how it is represented in pd, control messages vs. signal, what can be connected to what etc. The high-level stuff is great, sure. Both for production and learning. But if I am working on something and I need a reverse delay *right now* I fire up [plugin~] with an appropriate LADSPA plugin (or run it through some LADSPA host) and I do not take the time to reinvent the wheel. When I do have some time on my hands, I play with various concepts and read papers and theory and stuff like that.
You can learn Pd by yourself without taking classes about audio programming. But you do need to learn a little bit about digital audio if you want to make digital sounds. You need to learn about MIDI if you want to control MIDI gear (or control Pd with MIDI gear). You need to know some basics about 3D graphics and maybe even a touch of OpenGL if you want to create interactive 3D animations, you need to know about digital graphics formats and how pixels are represented in pd if you want to do work with video, images or whatnot. I think that pd documentation should document the specific classes and provide some basic concepts through tutorials. The detailed explanations of very specific DSP processes will be quite fine out in the cloud.
Anyway, the more i use it, the more i like it. Sometimes i wonder what Pd will be like 10 years from now. Whatever it'll be i'm excited!
Haha! :) I have been using Pd for 12-13 years. It hasn't really changed in any significant way, save for a lot of new externals and libraries. My hunch is that it will not change much but i think Hans is trying to prove us all wrong ;)
Best regards,
./MiS