hard off escribió:

i hope you got paid. because he certainly is.

Yes indeed he did pay me. On an earlier occasion, in which he wasn't paid at all (before he entered at Harvard), he also paid me. He is a very nice guy :)

Marco Donnarumma escribió:

Well, what is reasonable is quite subjective though.

You have a point :)

Anyway I referred to a "global" comparison, as you said the (_computing_) domain of both do overlap, but I specified the importance that IMHO the community supporting the project has. I personally don't think the community approach of Max is comparable to Pd.

I agree here. Well, I don't know if I agree that they are not comparable, I agree they are hugely different. But yes, when you need to chose between two "comparable" software, the kind of community surrounding them is a factor you have to take into account, and indeed, neither "kind of community" is better, it is just a matter of which one best suit your needs (i.e.: you prefer a company that sells the software and that can give you support for a fee, or that you can expect support from since you paid the software, or you may prefer an open source community where thanks to open source fixes and solutions are often quickly available)...... so it's like you said

reading documentation is not the only way to learn something. Again, the way you look for knowledge depends just on your personal approach.

Yes of course; I was just pointing out a particular aspect, that is documentation (in a somewhat wide sense though: documentation proper i.e. manual; help patches; tutorials...)

(anyway there is plenty of documentation about Pd,

Yeah, it is not a matter of quantity ;)

But however, I am a fan of Pd, don't make me feel like I am "on the opposite side" :)

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

Hallo, Pierre Massat hat gesagt: // Pierre Massat wrote:

Another thing that'd be nice to make available for new users would be a comprehensive set of generic patches, which would cover the whole range of DSP audio. A little bit like Puckette's audio help patches, only on a higher level (stuff like a basic drum machine, a comprehensive synth, granular synthesis, etc). I know that these aren't impossible to find, but it'd be nice to have it all in the same place.

The "rj" library developed for the creation of RjDj scenes, but also usable outside, tries exactly that. It is all abstractions, all run on Pd vanilla, no externals, not complicated -path setup needed, it has IMO pretty good help files (I wrote most, so I have to say this) and it provides a lot of everyday musician's tools plus some analysis and composition helpers.

It's deliberatly minimal, so that it doesn't overwhelm a newbie user with hundreds of objects. It's philosophy is "often-needed batteries included". For example, from [list]-abs it has a "listmap", "listdrip", "listreduce", "listfilter", "listrandom" and "listnth", but not the other 50 or so list objects. The included objects will solve about 80% of your everyday list-use, for the rest, you can still resort to the full [list]-abs objects. Similar approaches have been taken for other areas.

So far it has proven to be a successful base for many interesting music pieces written in Pd for RjDj. Check out trac.rjdj.me for details.

Ciao

Frank

Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:

I'd just add that one could start from the end of 3.audio.examples and 4.data.structures to get a decent overall idea of what Pd is capable of doing.

I learned most of the basic Pd knowledge from these patches (and the html-manual and the control.examples of course, which many people unfortunalty believe they can skip), but that was several years ago, and at that time, there wasn't much else. Today you get more detailed explanation of what these patches do in Miller's book, and you can take courses and workshops, read more books and tutorials and you have this great large community here and elsewhere on the web, which wasn't that big in the past.

In "rj" many of the DSP abstractions are actually taken from the 3.audio.examples with localized variable names (tables, sends), so that you can immediatly use them in your own work without doing that yourself again.

Ciao

Frank