[PD] Pd, Max/Msp, Reaktor, Plogue Bidule... How do these, compare?

[Michal Seta]

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 at 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