Is Adam Hyde on the list? I think its great for anyone to join,
seriously, the more the merrier. Already, the intro that I have been
assembling is drawing on the work of 10 or so people.

We discussed the idea of a manual a fair amount in the PDDP
meetings. I think most/all of us agreed that we want to try to make
a Pd manual that is completely made up of Pd patches. The point is
to highlight learning thru example for every single step. Having a
separate manual seems to highlight the book learning style more.
Yes, this will mean a lot of patches. I already have 60-ish for the
intro.

But I also just made a pager object which allows you to easily
navigate the pages like a manual. Its included in the most recent
test releases:

http://at.or.at/hans/pd/installers.html

Go to Help->Browser... then manuals/intro and load 0-pager.pd I
tested it on Windows and Mac OS X.

.hc

On Apr 19, 2006, at 5:07 PM, derek holzer wrote:

Hey HC and the gang,

Adam Hyde has been working on a PDF/HTML manual for getting PD up
and running. I've talked with him a bit about how beneficial such a
thing is versus a set of patches like the ones which have been
contributed here. But you might want to have a look at it:

http://www.flossmanuals.net/edit

I may be meeting with him soon about where it could go, and I'm
sure he's open for other suggestions as well.

Mark Polishook wrote:

...

Two comments: 1. the patches are very good at identifying core
concepts and explaining them. 2. But the hard thing about tutorial
writing is it's difficult to show how those small concepts relate
to larger artistic concerns.

I agree on both fronts. The main issue with PD is that people use
it for so many different things that demonstrating "artistic
concerns" would be pretty limited to what the author happens to be
doing with PD. All the same, I do find that there is a serious lack
of "demo" patches, or something like a "user library" that noobs
could have a look at for inspiration. Simple and not so simple but
usable tools, along the same lines as the User Library in Reaktor,
or maybe even the Pluggo patches from Cycling74 (except you can't
open those up, can you???). I tried to make something like that
with ParticleChamber, and I know that other stuff has come up on
the list when people ask about synth collections and the like.
Might be good to try to collect these kinds of abstractions
together into a library of sorts (a la RRRAD).

best, derek

-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 76: "Give the game away"

As we enjoy great advantages from inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. - Benjamin Franklin

isnt it possible to do both (a book man and a patch man)? they can easily fit together and trade content...

if anyone is interested in a traditional manual i have started a floss manual repository for collaborative dev of manuals. its not 'public' yet as i want to get some more manuals in there but its fully functional...

the url is: http://www.flossmanuals.net

an example of a 'finished' manual is the MuSE manual : http://www.flossmanuals.net/muse

and the PD manual is coming along, i would like to get it to the level of the MuSE manual soon, but i need to wrap it up in a nice skin and put a good index to it...you can for the meantime see the entire thing in one page: http://www.flossmanuals.net/bin/view/PureData/All?skin=basic

the repository allows for output in many formats: PDF (autoindexed, linked etc), tar, zip, chaptered html, printable html, and single page html.

there is also a shared image repository that can be contributed to and images can be edited,resized, etc through the default editor

if anyone is interested i would like to suggest a collab manual development utilising this system alongside the (very nice) idea of a manual made of PD patches

adam

..on Thu, Apr 20, 2006 at 12:40:28PM -0500, David Powers wrote:

I STRONGLY disagree with having a manual that is ONLY pd patches -- unless those patches are translated into PDF or HTML also.

Maybe I'm old fashioned, but I always print important reference material out onto notebooks, and I often do programming with paper and pencil. So, I'd first of all worry that a pd patch might require interactivity to fully understand what is happening. So, at a minimum, all patches should include enough text to understand the information, even if the patch isn't running.

Also, sometimes I reference things on work computers where I don't have pd. And, on Windows, many things still crash pd. There is nothing more annoying than being in the middle of studying things and suddenly having everything shut down and having to load it all up again.

So, I feel that a "manual" worthy of the name should allow one to access the information, regardless of having pd running or not. Perhaps the patches could just be converted to PDF, and somehow a page index created.

I LIKE "book learning", I often learn best that way--I have made many good pd patches and python programs riding the bus or train many times. In fact, I find that when I plan with pen and paper, my pd patches come out much better, and it's very helpful to have traditional reference materials when working in this way. Does everyone really have a problem with making a traditional manual for pd?

~David

On 4/19/06, Hans-Christoph Steiner hans@eds.org wrote:

...

Is Adam Hyde on the list? I think its great for anyone to join, seriously, the more the merrier. Already, the intro that I have been assembling is drawing on the work of 10 or so people.

We discussed the idea of a manual a fair amount in the PDDP meetings. I think most/all of us agreed that we want to try to make a Pd manual that is completely made up of Pd patches. The point is to highlight learning thru example for every single step. Having a separate manual seems to highlight the book learning style more. Yes, this will mean a lot of patches. I already have 60-ish for the intro.

But I also just made a pager object which allows you to easily navigate the pages like a manual. Its included in the most recent test releases:

http://at.or.at/hans/pd/installers.html

Go to Help->Browser... then manuals/intro and load 0-pager.pd I tested it on Windows and Mac OS X.

.hc

On Apr 19, 2006, at 5:07 PM, derek holzer wrote:

...

Hey HC and the gang,

Adam Hyde has been working on a PDF/HTML manual for getting PD up and running. I've talked with him a bit about how beneficial such a thing is versus a set of patches like the ones which have been contributed here. But you might want to have a look at it:

http://www.flossmanuals.net/edit

I may be meeting with him soon about where it could go, and I'm sure he's open for other suggestions as well.

Mark Polishook wrote:

...

Two comments: 1. the patches are very good at identifying core concepts and explaining them. 2. But the hard thing about tutorial writing is it's difficult to show how those small concepts relate to larger artistic concerns.

I agree on both fronts. The main issue with PD is that people use it for so many different things that demonstrating "artistic concerns" would be pretty limited to what the author happens to be doing with PD. All the same, I do find that there is a serious lack of "demo" patches, or something like a "user library" that noobs could have a look at for inspiration. Simple and not so simple but usable tools, along the same lines as the User Library in Reaktor, or maybe even the Pluggo patches from Cycling74 (except you can't open those up, can you???). I tried to make something like that with ParticleChamber, and I know that other stuff has come up on the list when people ask about synth collections and the like. Might be good to try to collect these kinds of abstractions together into a library of sorts (a la RRRAD).

best, derek

-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 76: "Give the game away"

---

---

As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

..on Sat, Apr 22, 2006 at 08:07:22PM +0200, Hans-Christoph Steiner wrote:

Installation manuals are the only thing that I can see that makes
sense with Pd.

really? what about for exmplaining externals that the user hasnt installed yet (etc) and what about graphic design, i dont think its such a good idea to think design isnt important when assiting readability etc...i think there are a lot of cases for a manual :)

adam

So this manual is a nice start. But it would be nice

to have that documentation integrated into puredata.org rather than
somewhere else.

.hc

On Apr 21, 2006, at 12:49 PM, adam wrote:

...

isnt it possible to do both (a book man and a patch man)? they can
easily fit together and trade content...

if anyone is interested in a traditional manual i have started a
floss manual repository for collaborative dev of manuals. its not
'public' yet as i want to get some more manuals in there but its fully functional...

the url is: http://www.flossmanuals.net

an example of a 'finished' manual is the MuSE manual : http://www.flossmanuals.net/muse

and the PD manual is coming along, i would like to get it to the
level of the MuSE manual soon, but i need to wrap it up in a nice
skin and put a good index to it...you can for the meantime see the entire thing in one page: http://www.flossmanuals.net/bin/view/PureData/All?skin=basic

the repository allows for output in many formats: PDF (autoindexed,
linked etc), tar, zip, chaptered html, printable html, and single
page html.

there is also a shared image repository that can be contributed to
and images can be edited,resized, etc through the default editor

if anyone is interested i would like to suggest a collab manual
development utilising this system alongside the (very nice) idea of
a manual made of PD patches

adam

..on Thu, Apr 20, 2006 at 12:40:28PM -0500, David Powers wrote:

...

I STRONGLY disagree with having a manual that is ONLY pd patches
-- unless those patches are translated into PDF or HTML also.

Maybe I'm old fashioned, but I always print important reference
material out onto notebooks, and I often do programming with paper and pencil.
So, I'd first of all worry that a pd patch might require interactivity to
fully understand what is happening. So, at a minimum, all patches should
include enough text to understand the information, even if the patch isn't
running.

Also, sometimes I reference things on work computers where I don't
have pd. And, on Windows, many things still crash pd. There is nothing more
annoying than being in the middle of studying things and suddenly having
everything shut down and having to load it all up again.

So, I feel that a "manual" worthy of the name should allow one to
access the information, regardless of having pd running or not. Perhaps the
patches could just be converted to PDF, and somehow a page index created.

I LIKE "book learning", I often learn best that way--I have made
many good pd patches and python programs riding the bus or train many times.
In fact, I find that when I plan with pen and paper, my pd patches come out
much better, and it's very helpful to have traditional reference
materials when working in this way. Does everyone really have a problem with
making a traditional manual for pd?

~David

On 4/19/06, Hans-Christoph Steiner hans@eds.org wrote:

...

Is Adam Hyde on the list? I think its great for anyone to join, seriously, the more the merrier. Already, the intro that I have
been assembling is drawing on the work of 10 or so people.

We discussed the idea of a manual a fair amount in the PDDP meetings. I think most/all of us agreed that we want to try to make a Pd manual that is completely made up of Pd patches. The point is to highlight learning thru example for every single step. Having a separate manual seems to highlight the book learning style more. Yes, this will mean a lot of patches. I already have 60-ish for the intro.

But I also just made a pager object which allows you to easily navigate the pages like a manual. Its included in the most recent test releases:

http://at.or.at/hans/pd/installers.html

Go to Help->Browser... then manuals/intro and load 0-pager.pd I tested it on Windows and Mac OS X.

.hc

On Apr 19, 2006, at 5:07 PM, derek holzer wrote:

...

Hey HC and the gang,

Adam Hyde has been working on a PDF/HTML manual for getting PD up and running. I've talked with him a bit about how beneficial such a thing is versus a set of patches like the ones which have been contributed here. But you might want to have a look at it:

http://www.flossmanuals.net/edit

I may be meeting with him soon about where it could go, and I'm sure he's open for other suggestions as well.

Mark Polishook wrote:

...

Two comments: 1. the patches are very good at identifying core concepts and explaining them. 2. But the hard thing about tutorial writing is it's difficult to show how those small concepts relate to larger artistic concerns.

I agree on both fronts. The main issue with PD is that people use it for so many different things that demonstrating "artistic concerns" would be pretty limited to what the author happens to be doing with PD. All the same, I do find that there is a serious lack of "demo" patches, or something like a "user library" that noobs could have a look at for inspiration. Simple and not so simple but usable tools, along the same lines as the User Library in Reaktor, or maybe even the Pluggo patches from Cycling74 (except you can't open those up, can you???). I tried to make something like that with ParticleChamber, and I know that other stuff has come up on the list when people ask about synth collections and the like. Might be good to try to collect these kinds of abstractions together into a library of sorts (a la RRRAD).

best, derek

-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 76: "Give the game away"

---

---

---

As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin
Franklin

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

...

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

--

Adam Hyde ~/.nl

selected projects http://www.xs4all.nl/~adam

the streaming suitcase http://www.streamingsuitcase.com

r a d i o q u a l i a http://www.radioqualia.net

Free as in 'media' email : adam@xs4all.nl mobile : + 31 6 186 75 356 (Netherlands mobile)

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

---

---

              ?El pueblo unido jam?s ser? vencido!

Hi HC, Adam,

Hans-Christoph Steiner wrote:

I am not opposed to things like PDB or ways of searching for existing objects. But if you are going to learn the object, functional examples work best. But a manual would not be a good way to search for objects.

In general, I don't really agree that a manual with pictures of patches would be very useful. The functionality to learn and experiment by changing things really isn't there.

OTOH, one thing that people in my workshops are always asking for is a list of all the objects, including the externals. There isn't really one place to get all this, except online with the PDB, but that's not a good reference when you don't have any net access. I tried maintaining a text file with as many as I could, but it's very incomplete.

My suggestion would be to make a "dictionary" of objects, maybe sorted by name, library or general function (dataflow, 3d, audio, video, I/O...), such as the directories which were made by the user community for CSound. That might be useful as a PDF or hardcopy even. The PDcyclopia?

d.

I think that there should be two strategies, a traditional 'manual' and a PD patch manual. I dont see any need really for having just one. Material can easily be copied between the two.

the PD patch manual is a very exciting approach, more exciting I think than a 'traditional' approach, however, just cause i'm conservative and boring I will keep scratching away at the manual i started at flossmanuals, and if anyone wants to pitch in that would be cool :)

adam

..on Tue, Apr 25, 2006 at 02:34:16PM -0500, David Powers wrote:

I think there is a huge need for exactly something like what Derek mentions--a reference manual. I don't have the internet at home, and when I'm planning something like writing a program, my first step is to use pencil and paper, and sketch out the parts of my design, and try to decide the most logical way to build and test my application. A real reference encyclopedia would make this task MUCH easier. It's not a task that PD really lends itself too, as I tend to get all mucked up, if I didn't figure out the answer on paper first. For me, the computer screen makes it too easy to just start patching away without a clear idea of the logic I need.

However, I think there is a strong need for a manual in another area, and that is overall program design and application building in Pure Data. What different ways are there to conceptualize a Pure Data application? What approaches can one take in application design? What decisions should be made in advance? How can one do object-oriented PD (there are at least some parallels), and how might that differ from other approaches? What are pitfalls to avoid? What are typical problems that one can expect to encounter, including problems relating to different platforms and limitations of PD, and what are good strategies to overcome these limitations? What are different ways to do GUI and control, and to seperate the GUI from the rest of the patch? How to optimize a patch, or reduce CPU load on a hungry patch? How can you do testing, to see if your idea is even feasible with a given set of CPU resources?

At the very least, a thorough FAQ is essential. But even better, a manual that has an FAQ index pointing to the answers in context. Remember, some people coming to PD, don't have real programming experience. So teaching some programming concepts might be helpful--I myself don't totally know the best way to work on large scale design in PD. I mostly learned programming on my own, so I'm definitely lacking in ideas about how bigger programming projects are organized. I don't even know what philosophies exist (extreme programming I've heard of, but I'm sure there's many more.)

THESE are the questions that I currently don't see being addressed, except ad hoc in email exchanges on the list. They are, I would suggest, appropriate to a "manual" on PD programming, as it's not just a matter of how a particluar object works, but would include insights gained from the real world of programming. And honestly, when I open up PD, I'm most likely working on a particular patch or problem. I want to have my reference material open next to me. I don't want to search through someone's tutorial patches for the answer to one specific problem, especially if its a more general philosophy/design question, rather than a question about a specific object.

If such a manual existed, alongside a reference manual of all the objects and their inputs and outputs, I think PD would have great potential to grow its user base.

Just remember this: If I'm considering using a new programming language or new musical software, the first thing I do is browse the website and look at the manual. If the manual looks good, I'm FAR more likely to give the language a serious try. This is part of the reason why I didn't try PD at all for a year after I first considered using it! To give another example, I started programming in ChucK recently, partly because it has a simple, nicely written manual (plus it's 10x quicker to develop some things, like granular synthesis, than PD, and it has the working STK stuff that I can't seem to get for PD Windows.) Reading the manual a couple of times convinced me that it would do some interesting things and was worth a try. I'm sure that I'm not the only user out there that approaches things in this way. Accessible documentation is important -- and by accessible, I mean accessible outside of the program in question.

~David

On 4/25/06, derek holzer derek@x-i.net wrote:

...

Hi HC, Adam,

Hans-Christoph Steiner wrote:

...

I am not opposed to things like PDB or ways of searching for existing objects. But if you are going to learn the object, functional examples work best. But a manual would not be a good way to search for objects.

In general, I don't really agree that a manual with pictures of patches would be very useful. The functionality to learn and experiment by changing things really isn't there.

OTOH, one thing that people in my workshops are always asking for is a list of all the objects, including the externals. There isn't really one place to get all this, except online with the PDB, but that's not a good reference when you don't have any net access. I tried maintaining a text file with as many as I could, but it's very incomplete.

My suggestion would be to make a "dictionary" of objects, maybe sorted by name, library or general function (dataflow, 3d, audio, video, I/O...), such as the directories which were made by the user community for CSound. That might be useful as a PDF or hardcopy even. The PDcyclopia?

d.

-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 109: "Lost in useless territory"

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On Apr 25, 2006, at 9:34 PM, David Powers wrote:

I think there is a huge need for exactly something like what Derek
mentions--a reference manual. I don't have the internet at home,
and when I'm planning something like writing a program, my first
step is to use pencil and paper, and sketch out the parts of my
design, and try to decide the most logical way to build and test my
application. A real reference encyclopedia would make this task
MUCH easier. It's not a task that PD really lends itself too, as I
tend to get all mucked up, if I didn't figure out the answer on
paper first. For me, the computer screen makes it too easy to just
start patching away without a clear idea of the logic I need.

This has been discussed at length in PDDP meetings. We have designed
a system of meta data in help patches. This meta data will
automatically parsed and used to generate a searchable index. We
have the plan, we just need help implementing.

http://puredata.org/dev/pddp

However, I think there is a strong need for a manual in another
area, and that is overall program design and application building
in Pure Data. What different ways are there to conceptualize a Pure
Data application? What approaches can one take in application
design? What decisions should be made in advance? How can one do
object-oriented PD (there are at least some parallels), and how
might that differ from other approaches? What are pitfalls to
avoid? What are typical problems that one can expect to encounter,
including problems relating to different platforms and limitations
of PD, and what are good strategies to overcome these limitations?
What are different ways to do GUI and control, and to seperate the
GUI from the rest of the patch? How to optimize a patch, or reduce
CPU load on a hungry patch? How can you do testing, to see if your
idea is even feasible with a given set of CPU resources?

At the very least, a thorough FAQ is essential. But even better, a
manual that has an FAQ index pointing to the answers in context.
Remember, some people coming to PD, don't have real programming
experience. So teaching some programming concepts might be helpful-- I myself don't totally know the best way to work on large scale
design in PD. I mostly learned programming on my own, so I'm
definitely lacking in ideas about how bigger programming projects
are organized. I don't even know what philosophies exist (extreme
programming I've heard of, but I'm sure there's many more.)

http://puredata.org/docs/faq

Its a wiki! Please update it! This page could easily be included
in the Pd-extended distro too.

THESE are the questions that I currently don't see being addressed,
except ad hoc in email exchanges on the list. They are, I would
suggest, appropriate to a "manual" on PD programming, as it's not
just a matter of how a particluar object works, but would include
insights gained from the real world of programming. And honestly,
when I open up PD, I'm most likely working on a particular patch or
problem. I want to have my reference material open next to me. I
don't want to search through someone's tutorial patches for the
answer to one specific problem, especially if its a more general
philosophy/design question, rather than a question about a specific
object.

If such a manual existed, alongside a reference manual of all the
objects and their inputs and outputs, I think PD would have great
potential to grow its user base.

Please have a look at the intro tutorial/manual materials in CVS: doc/tutorials/intro doc/tutorials/sound doc/tutorials/visual doc/tutorials/networking doc/tutorials/physical

This is a start for such a manual, its also included in the test
releases on my site.

.hc

Just remember this: If I'm considering using a new programming
language or new musical software, the first thing I do is browse
the website and look at the manual. If the manual looks good, I'm
FAR more likely to give the language a serious try. This is part of
the reason why I didn't try PD at all for a year after I first
considered using it! To give another example, I started
programming in ChucK recently, partly because it has a simple,
nicely written manual (plus it's 10x quicker to develop some
things, like granular synthesis, than PD, and it has the working
STK stuff that I can't seem to get for PD Windows.) Reading the
manual a couple of times convinced me that it would do some
interesting things and was worth a try. I'm sure that I'm not the
only user out there that approaches things in this way. Accessible
documentation is important -- and by accessible, I mean accessible
outside of the program in question.

~David

On 4/25/06, derek holzer derek@x-i.net wrote: Hi HC, Adam,

Hans-Christoph Steiner wrote:

...

I am not opposed to things like PDB or ways of searching for

existing

...

objects. But if you are going to learn the object, functional

examples

...

work best. But a manual would not be a good way to search for

objects.

In general, I don't really agree that a manual with pictures of
patches would be very useful. The functionality to learn and experiment by changing things really isn't there.

OTOH, one thing that people in my workshops are always asking for is a list of all the objects, including the externals. There isn't
really one place to get all this, except online with the PDB, but that's not a
good reference when you don't have any net access. I tried maintaining a
text file with as many as I could, but it's very incomplete.

My suggestion would be to make a "dictionary" of objects, maybe sorted by name, library or general function (dataflow, 3d, audio, video, I/O...), such as the directories which were made by the user community for CSound. That might be useful as a PDF or hardcopy even. The
PDcyclopia?

d.

-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 109: "Lost in useless territory"

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos
Williams

On Apr 26, 2006, at 9:49 PM, David Powers wrote:

Hi, sorry I don't understand this CVS address you give below--Where
do I find these docs?

They are relative to the CVSROOT. On the web, the CVSROOT is:

http://cvs.sourceforge.net/viewcvs.py/pure-data/

Also, I don't really know enough about programming generally, and
PD, to write an FAQ. I don't really know the answers to the
questions I posed, which is probably why my PD development hasn't
been too successful, except for one GEM live-VJ project.

So, the best I can do is plagerize other people's work, which I
don't think is a good idea. But if people want to give me
permission to plagarize and modify their words, maybe I could help.
I'm a good editor.

But I am sure you know enough to contribute to a FAQ, at the vary
least editing existing questions, or even better, summarizing threads
from this list. Since all Pd code is free, I think we can all safely
assume that all of the words on this list are free. If need be, we
should make it explicit. As for me, anything I write on this list is
public domain. Its not plagiarism, its collaborative work.

Anyway, if anyone has stuff that could be included in an FAQ, I'd
be happy to try and update the Wiki. Another possibility, I could
ask questions to the list one at a time, collect answers, and post
them to the wiki FAQ, if people think this is a good idea.

That sounds like a great idea if you are willing to do it. If you
made a FAQ entry for each question that you resolved on this list,
we'd all be a lot better off. I have tried on and off to do that...

.hc

~David

http://puredata.org/docs/faq

Its a wiki! Please update it! This page could easily be
included in the Pd-extended distro too.

Please have a look at the intro tutorial/manual materials in CVS: doc/tutorials/intro doc/tutorials/sound doc/tutorials/visual doc/tutorials/networking doc/tutorials/physical

This is a start for such a manual, its also included in the test
releases on my site.

.hc

Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos
Williams

On Tue, 25 Apr 2006, David Powers wrote:

How can one do object-oriented PD (there are at least some parallels), and how might that differ from other approaches?

First you have to avoid those who say that PD is only for music and/or video; they can't put the word "application" or "program" on a patch or a set of patches, it has to be called "patches".

Second you have to avoid those who say PD isn't object-oriented and especially those who think that you should not use anything that "looks" too object-oriented because it wouldn't fit the "dataflow paradigm", whatever that is.

Third is a rule for OOP in general, in any language: the final goal is never to make a program "more OOP", it's to make a program better, by any "paradigm" necessary.

What are typical problems that one can expect to encounter, including problems relating to different platforms and limitations of PD, and what are good strategies to overcome these limitations?

heeee... getting abstraction arguments to work exactly like external arguments? Sometimes things are easier in C than in Pd (and that's sad).

But that's a very wide question and the answers you'll get will never paint a complete picture, no matter which programming language it is being asked about, even though I think that Pd has more holes than almost all programming languages.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

On Sun, 30 Apr 2006, Tim Blechmann wrote:

On Sun, 2006-04-30 at 12:58 -0400, Mathieu Bouchard wrote:

...

asked about, even though I think that Pd has more holes than almost all programming languages.

such as? (i'm honestly curious, what you're thinking about)

Abstraction arguments are shittier in Pee Dee than in BASH (Bourne Shell).
At least they're on par with those of .BAT files. The only two levels below that one are called GOSUB and GOTO.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

On Sun, Apr 30, 2006 at 12:58:32PM -0400, Mathieu Bouchard wrote:

On Tue, 25 Apr 2006, David Powers wrote:

...

How can one do object-oriented PD (there are at least some parallels), and how might that differ from other approaches?

First you have to avoid those who say that PD is only for music and/or video; they can't put the word "application" or "program" on a patch or a set of patches, it has to be called "patches".

Second you have to avoid those who say PD isn't object-oriented and especially those who think that you should not use anything that "looks" too object-oriented because it wouldn't fit the "dataflow paradigm", whatever that is.

Third is a rule for OOP in general, in any language: the final goal is never to make a program "more OOP", it's to make a program better, by any "paradigm" necessary.

Fourth, watch out for communists, who are all out to get you.

paint a complete picture, no matter which programming language it is being asked about, even though I think that Pd has more holes than almost all programming languages.

So why are you still using it?

Best,

Chris.

chris@mccormick.cx http://mccormick.cx

On Mon, May 01, 2006 at 10:36:51AM -0400, Mathieu Bouchard wrote:

On Mon, 1 May 2006, Chris McCormick wrote:

...

...

Third is a rule for OOP in general, in any language: the final goal is never to make a program "more OOP", it's to make a program better, by any "paradigm" necessary.

Fourth, watch out for communists, who are all out to get you.

I'd rather have you reply with interesting ideas, but I can deal with flames too. It's sort of disappointing, though.

Yep, I feel kind of embarrassed about the tone of my reply. I guess I hadn't had my coffee yet. It is pretty frustrating though, after we had such a civil email exchange about the advantages of considering puredata as a programming language and trying to fit Pd into various paradigms, to have you completely misrepresent and mock the other side of the argument in such a ridiculous fashion. Let's agree on more mature discussion from now on.

Best,

Chris.

chris@mccormick.cx http://mccormick.cx

On Tue, May 02, 2006 at 12:13:50AM -0400, Mathieu Bouchard wrote:

On Tue, 2 May 2006, Chris McCormick wrote:

I would like that those who care, go read the original thread, and they'll

Sure, sounds good. I think we might be the only ones reading though. ;)

It could be that I took your reply to David as referencing our previous conversation on pd-dev in error, and if that's the case as you seem to indicate, then I apologise for the second time for that blunder and my insensitive reply. Since it's come up again though, I'd like to re-iterate what I was trying to say in those emails, because I think it's important.

You have often expressed exasperation at the shortcomings of Pd in terms of using it as a programming language. What I have been trying to say is that maybe the original intention of the Pd language isn't to be a fully fledged programming language, but instead an artist's tool with some dataflow programming-like features. I think it would ease some of your concerns about Pd if you saw it that way, and maybe you would ease back a bit on the sometimes hostile attacks and just write code to make it do what you want instead. There's no point in saying that the horse doesn't have a long enough trunk, if the horse doesn't even pretend to be an elephant.

Yrs, amicably,

Chris.

chris@mccormick.cx http://mccormick.cx

when INXS was making the pop charts ???

• ,,, http://en.wikipedia.org/wiki/INXS...

AvS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................

` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +

`  |# -laboratory for live electro-acoustic music- #            |
   |             http://www.schreck.nl/                         |
   |             http://www.xs4all.nl/~schreck/                 |
 ` *===========================================================++
 ` |Compositions http://www.xs4all.nl/~schreck/html/compo.html  |
 ` |Samples      http://www.xs4all.nl/~schreck/html/samp.html   |
 ` |Patches      http://www.xs4all.nl/~schreck/html/pat.html    |
 ` |Videos       http://www.xs4all.nl/~schreck/html/video.html  |

 ` |Scores       http://www.xs4all.nl/~schreck/html/scores.html |

   *===========================================================++

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................

I'll admit to that...

If by MAX you mean Max/MSP and or jMax then I'm your case-in-point.

./d5

On May 5, 2006, at 5:12 PM, Mathieu Bouchard wrote:

I was thinking about back when MAX was invented. That's around 1987. To be fair, PureData introduced some new concepts, but most Pd users use Pd as a MAX clone.

On Sat, 6 May 2006, Frank Barknecht wrote:

Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

...

I was thinking about back when MAX was invented. That's around 1987. To be fair, PureData introduced some new concepts, but most Pd users use Pd as a MAX clone.

Except that Pd users tend to do audio signal processing as well.

I'm curious about what are the differences between Pd/MSP's signal model and the signal models of earlier prototypes (those that were implemented in hardware, such as ISPW). Does anyone know?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

On Fri, May 05, 2006 at 11:35:44PM +0200, Tim Blechmann wrote:

On Fri, 2006-05-05 at 16:34 -0400, Mathieu Bouchard wrote:

...

...

that maybe the original intention of the Pd language isn't to be a

fully

...

fledged programming language, but instead an artist's tool with some dataflow programming-like features.

well, especially being an artistic tool, it shouldn't require the user to learn 1001 workarounds for trivial problems, nor should the user have to worry about obscure message vs. list problems ...

True. It guess you'd hope that it would be as easy as possible to make art with such a tool.

...

I'm always talking about what Pd could become and all I get answered is what Pd was meant to be.

i'm not sure, if anyone can say, what pd is meant to be ... but matju is right about one thing ... pd can't be improved, when everyone ignores it's weaknesses ("you don't want to load soundfiles clickfree", "you don't need to use tables on the x86_64 architecture") ...

I am not against making Pd better. I am not against talking about what features would be good in Pd. I am not against someone forking Pd and making something amazing and new and wonderful. I am not against somebody cloning all the ideas in Pd and making something which is a generic dataflow programming environment with all the bells and whilstles of a fully fledged programming language. That is all excellent - more great free software for all of us.

The thing I find tiresome is people's attitude and disrespect towards other developers when they find what they see as flaws in Pd. That is probably all in my head since nobody else seems to see it, and anyway, I'm not a developer so I should let others continue with their opinions and hostile attitudes, and leave it alone and just go back to making weird sounds with computers.

Apologies for the disturbance. Nothing to see, move along.

Best regards,

Chris.

chris@mccormick.cx http://mccormick.cx

On Sat, May 06, 2006 at 03:39:36PM -0400, Mathieu Bouchard wrote:

On Sat, 6 May 2006, Chris McCormick wrote:

The disrespect is very rarely personal; it's all about the ideas and not the individuals.

I am not sure if you have ever experienced this, but sometimes when somebody disrespects your idea, it's hard not to take it personally. It all comes down to the tone of your language. One must be extra careful in the case of email, as we all know.

In the four years I've been here there have only been a handful of exceptions. As far as I remember, those were one case of "freaking caveman", one case of "pd-guided missile up your ass" and one case of "communists are out to get you", and that's about it, almost all of the other 40000 emails were fine. That's a quite good average compared to some other mailing-lists.

Heheh, so what yr saying is that 66% of all disrespect on this list has been directed at you?

"communists are out to get you"

Actually I think I made that joke twice - once was "left wing conspiracy". Neither was intended to be disrespectful at all (or to imply that you are right wing), but rather a humorous way of saying that I thought you were seeing a unified opposition to your ideas where there really was none. You can think of it as a disrespect of that idea not a disrespect of yourself. Maybe it's similar to how I am seeing disrespect of developers where there is none.

Best,

Chris.

chris@mccormick.cx http://mccormick.cx

when everyone ignores it's weaknesses ("you don't want to load soundfiles

...

clickfree",

-That's probably why jMax needed at least two cpu's to run 'clickfree'.

AvS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................

` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +

`  |# -laboratory for live electro-acoustic music- #            |
   |             http://www.schreck.nl/                         |
   |             http://www.xs4all.nl/~schreck/                 |
 ` *===========================================================++
 ` |Compositions http://www.xs4all.nl/~schreck/html/compo.html  |
 ` |Samples      http://www.xs4all.nl/~schreck/html/samp.html   |
 ` |Patches      http://www.xs4all.nl/~schreck/html/pat.html    |
 ` |Videos       http://www.xs4all.nl/~schreck/html/video.html  |

 ` |Scores       http://www.xs4all.nl/~schreck/html/scores.html |

   *===========================================================++

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................

jMax's problems were even worse than what you say. The messagesystem (which we used for video) couldn't run clickfree either, with hiccups longer than 100 ms! and i'm not sure that they were fixable by adding an extra CPU.

-There is a big misunderstanding about the purpose for what jMax was designed in the first place: a replacement for the Ircam Signal Processing Workstation a.k.a ISPW. Period. At that time approx. 1991-1995 signal processing meant in their terminology: audio-processing. This was done previously with dedicated processors:DSP's. Subsequently it became possibleto this with general CPU's like PPC, MIPS, UltraSparc. etc., etc., etc... Intel had a lousy reputation in this. They later on discovered there was a market for this so up comes MMX, SSE...

IRCAM wanted a 'virtual ISPW' and found this at that time in SGI machines with multiple cpu's and the OS (Irix) that offered, through the REACT extensions, an adequate realtime response (under 20 milliseconds...), hence jMax. Therefore the controlling host became a Java-gui on cpu 1 and all the signal processing stuff were put on other cpu's. Now under Irix you can assign these functions to different processors, because REACT allows you to do so. Thus if you wanted to do video use a separate processor!

However one can question whether it was a clever thing to do this seperation, on the other hand with current dualcore processors becoming standard for the next couple of years, maybe it ought to be revived. Perhaps somebody ought to contact Francois Dechelle in advance.. I think, by the way, IRCAM could have supported it slightly more decently with their lists.

AvS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................

` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +

`  |# -laboratory for live electro-acoustic music- #            |
   |             http://www.schreck.nl/                         |
   |             http://www.xs4all.nl/~schreck/                 |
 ` *===========================================================++
 ` |Compositions http://www.xs4all.nl/~schreck/html/compo.html  |
 ` |Samples      http://www.xs4all.nl/~schreck/html/samp.html   |
 ` |Patches      http://www.xs4all.nl/~schreck/html/pat.html    |
 ` |Videos       http://www.xs4all.nl/~schreck/html/video.html  |

 ` |Scores       http://www.xs4all.nl/~schreck/html/scores.html |

   *===========================================================++

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................

x86-based SIMD didn't do floats until SSE1 and 3DNOW, but it doesn't matter because jMax never used it and Miller's Pd never used it.

-Which is not what I'm saying, if you read more carefully. It's not even a point I'm trying to make.

Does MAX/MSP use SSE and/or Altivec in its signal processing ?

-Both are used (on WindowsMax and OSX-Max).

I think that the client/server separation is very worthwhile.

-I think so too.

The dropouts are caused by not enough separation and/or by buffer-clogging.

-Completely agree on that one too. So are in the context of jMax are we talking about crappy programming or crappy design?

...

on the other hand with current dualcore processors becoming standard for the next couple of years, maybe it ought to be revived.>

You must be kidding. Pd already has a separate GUI thread (wish pd.tk). The only advantage jMax has, is that all its GUI lives in that thread,

-Indeed. Making it probably a better design, because it isn't in the way.

whereas Pd does lots of unnecessary coupling.

-Agreed.

The amount of work left to make Pd cleanly client-server-separated is almost nothing.

-So why isn't that done?

Then there's the fact that at this point, the issue of getting audio running fast enough, has already disappeared.

-To what extent?

If it wasn't the case, many more people would spend time on Pd devel_0_39, which can be up to 4 times faster than Miller's Pd (except for fft~ in which case it's even faster).

-Maybe people don't find that an issue.

Bringing in a second processor is thus not that useful.

-Depends what you're trying to do, I guess...

...

I think, by the way, IRCAM could have supported it slightly more decently with their lists.

What do you mean?

-I remember that many times awkward questions were avoided or not even answered. Also that the complete archive has been removed is rather odd to say the least.

AvS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................

` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +

`  |# -laboratory for live electro-acoustic music- #            |
   |             http://www.schreck.nl/                         |
   |             http://www.xs4all.nl/~schreck/                 |
 ` *===========================================================++
 ` |Compositions http://www.xs4all.nl/~schreck/html/compo.html  |
 ` |Samples      http://www.xs4all.nl/~schreck/html/samp.html   |
 ` |Patches      http://www.xs4all.nl/~schreck/html/pat.html    |
 ` |Videos       http://www.xs4all.nl/~schreck/html/video.html  |

 ` |Scores       http://www.xs4all.nl/~schreck/html/scores.html |

   *===========================================================++

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................

On Sun, 7 May 2006, geiger wrote:

First, I do not think that technical reasons led to the fact that jMax got abandoned.

Whose abandon you are talking about? There wasn't just IRCAM involved with jMax.

I don't think it's fair to pick either technical reasons or social reasons as being decisive. It's not an either-or, it's an interaction of both kinds of reasons.

jMax died because it was not possible to get the community support, and when they had no money any more it just got closed. At that time probably most people were already using Pd or both, so it was not a big loss.

Why wasn't it possible for jMax to get community support? Why were jMax users looking into Pd? It's at once because Pd already had a bigger community, but also because jMax wasn't technically superior enough, and also because it had some serious technical drawbacks that made its users look for something else. The announcement of jMax 4.x was the final demise because instead of making technical changes that would help its community grow, it made technical changes that made its community run away. jMax 4.x makes the most sense if you see it already as the MAX plugin it was going to be morphed into, but at the same time, the PyMax project was trying to replace JAVA by Python, which would have made jMax more acceptable by free-software developers, who are the part of the community that could have helped IRCAM make jMax something more technically acceptable.

My point is that technical and social reasons are interlocked.

Maybe it was a mistake to make jMax free software, and therefore compete with Pd directly. But maybe it was its salvation at that time.

It would've been a worse decision to compete against C74-MAX directly, because it had a bigger user base than Pd (and still has), and was harder to technically catch up with than Pd, and also is backed with a bigger company than a team of 2-4 people at IRCAM.

This can't happen with PD because there is no money behind its development. Its based on a different development model.

There is obviously money behind the development of Pd. Intel has funded both Pd and GEM.

http://crca.ucsd.edu/~msp/bio.htm http://puredata.org/Members/zmoelnig/GemFAQ/WhatIsGEM/src

Apart from that, there are a number of Pd developers who are using university resources to develop Pd, without being hired specifically for that.

The development model is different, it's more decentralized, but that doesn't mean that there is no money involved.

If Miller had to stop to develop Pd now, we would soon see several versions of Pd popping up, competing against each other. This is already the case actually,

They aren't quite competitive as of now, though that could change any month. There needs some kind of trigger to get things going. Currently there aren't enough developers willing to work on the core.

it is not bad for PD per se, but it can be a terrible loss of energy.

It's only a terrible loss of energy if you think that this energy could be going anywhere else and if you think that Pd is perfect as it is.

but still I think it is important to focus our efforts.

Whose ideas should we focus our efforts on?

I don't understand PD develpers who complain about missing features, or how main Pd development is handled.

That is an example of a social reason. The "complaining" also happens to be a call for discussion, for alternatives and a way to find like-minded people, some of whom can become allies. If your changes to pd are small then it's easier to code them alone. If you'd rather change pd by yourself then you don't need to look for allies. If you don't need to look for allies for your changes to pd then you don't need to understand why and how someone would.

Its noone else but themselves who can change this situation.

I pretty damn know that and still trying to figure how to do it without discouraging myself again *and* without going bankrupt. I'm looking support from people who care. It also means getting a lot of non-support from people who non-care. That's a fact of life.

Miller has always been very open to contributions

Compared to the jMax team, yes...

Compared to the MAX/MSP team, very much... ;-)

However, many other open-source projects are intensely more collaborative than Pd, in such a way that (the core of) Pd, jMax and MAX/MSP look about as collaborative as each other.

he includes patches when time permits and also explains why he doesn't include others.

I haven't found his explanations to be always particularly explaining, and I don't expect them to always be, but there are some biggies for which his explanations were even more disconcerting than the lack thereof.

I don't mean just the patch submission system, I also mean discussions that lead potential patch submitters to decide whether submitting patches is worth doing.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

On Sun, May 07, 2006 at 03:22:48PM -0400, Mathieu Bouchard wrote:

On Sun, 7 May 2006, geiger wrote:

However, many other open-source projects are intensely more collaborative than Pd, in such a way that (the core of) Pd, jMax and MAX/MSP look about as collaborative as each other.

I don't have a good metric for this, but it seems that since the patch tracker was started, many more patches have gone into Miller's Pd than used to. It also seems like he has rejected some patches for technical reasons and instead of fixing those technical faults and re-submitting, people have just let the patches languish. One of the ones that makes me sad is your tool tips patch - how cool it would be if inlets had tooltips!

...

he includes patches when time permits and also explains why he doesn't include others.

I haven't found his explanations to be always particularly explaining, and I don't expect them to always be, but there are some biggies for which his explanations were even more disconcerting than the lack thereof.

Linus Torvalds and Andrew Morton often drop patches completely silently. Andrew Morton gave a really good explanation of why this is neccesary at Linux.conf.au a couple of years back. It's the right of the "benevolent dictator" to accept or reject submissions for whatever reason. And it's the right of the developer to fork if they don't like the direction the mainline is going in. It's also their right to be too busy to explain things, though as we see with Pd this might discourage some people from contributing.

Perhaps it is reactions to his "disconcerting explanations" that is putting him off from giving more detailed explanations? Who knows. My point all along has been that a little bit of politeness and respect can go a long way.

I don't mean just the patch submission system, I also mean discussions that lead potential patch submitters to decide whether submitting patches is worth doing.

Yeah, it seems like Miller doesn't always indicate the development direction he is going in, and if he did that it might help things along. This could be because he isn't employed by someone like the OSDL and is pretty busy as a researcher. Then again, there are a heap of tasks in the TODO file which people seem to be ignoring and working on other stuff instead, often stuff that is quite perpendicular to the development direction of Pd main.

Best,

Chris.

chris@mccormick.cx http://mccormick.cx

On Sun, 7 May 2006, Mathieu Bouchard wrote:

On Sun, 7 May 2006, geiger wrote:

...

First, I do not think that technical reasons led to the fact that jMax got abandoned.

Whose abandon you are talking about? There wasn't just IRCAM involved with jMax.

I don't think it's fair to pick either technical reasons or social reasons as being decisive. It's not an either-or, it's an interaction of both kinds of reasons.

You are right, both are interacting, I just meant that these were mainly social reasons, but then, both are so dependent on each other that you can not really tell.

...

jMax died because it was not possible to get the community support, and when they had no money any more it just got closed. At that time probably most people were already using Pd or both, so it was not a big loss.

Why wasn't it possible for jMax to get community support? Why were jMax users looking into Pd? It's at once because Pd already had a bigger community, but also because jMax wasn't technically superior enough, and also because it had some serious technical drawbacks that made its users look for something else. The announcement of jMax 4.x was the final demise because instead of making technical changes that would help its community grow, it made technical changes that made its community run away. jMax 4.x makes the most sense if you see it already as the MAX plugin it was going to be morphed into, but at the same time, the PyMax project was trying to replace JAVA by Python, which would have made jMax more acceptable by free-software developers, who are the part of the community that could have helped IRCAM make jMax something more technically acceptable.

My point is that technical and social reasons are interlocked.

Its a good point, and you probably have more insight into the community part of jMax. If I recall there have been some sort of split versions of jMax too.

...

Maybe it was a mistake to make jMax free software, and therefore compete with Pd directly. But maybe it was its salvation at that time.

It would've been a worse decision to compete against C74-MAX directly, because it had a bigger user base than Pd (and still has), and was harder to technically catch up with than Pd, and also is backed with a bigger company than a team of 2-4 people at IRCAM.

...

This can't happen with PD because there is no money behind its development. Its based on a different development model.

There is obviously money behind the development of Pd. Intel has funded both Pd and GEM.

http://crca.ucsd.edu/~msp/bio.htm http://puredata.org/Members/zmoelnig/GemFAQ/WhatIsGEM/src

Apart from that, there are a number of Pd developers who are using university resources to develop Pd, without being hired specifically for that.

The development model is different, it's more decentralized, but that doesn't mean that there is no money involved.

Yes, that kind of what I wanted to say. I think the intel grant is not relevant nowadays.

...

If Miller had to stop to develop Pd now, we would soon see several versions of Pd popping up, competing against each other. This is already the case actually,

They aren't quite competitive as of now, though that could change any month. There needs some kind of trigger to get things going. Currently there aren't enough developers willing to work on the core.

...

it is not bad for PD per se, but it can be a terrible loss of energy.

It's only a terrible loss of energy if you think that this energy could be going anywhere else and if you think that Pd is perfect as it is.

Yes, exactly, and I think this energy could go somewhere else :)

...

but still I think it is important to focus our efforts.

Whose ideas should we focus our efforts on?

Ours ?

...

I don't understand PD develpers who complain about missing features, or how main Pd development is handled.

That is an example of a social reason. The "complaining" also happens to be a call for discussion, for alternatives and a way to find like-minded people, some of whom can become allies. If your changes to pd are small then it's easier to code them alone. If you'd rather change pd by yourself then you don't need to look for allies. If you don't need to look for allies for your changes to pd then you don't need to understand why and how someone would.

I have been constantly looking for allies. I had to look for allies when establishing the CVS, I had to look for allies when trying to get the patches system going. There was plenty of opposition against both systems, so it was not an easy task. I am still trying to get you as an ally or to get Tim back. I sort of know how you feel.

...

Its noone else but themselves who can change this situation.

I pretty damn know that and still trying to figure how to do it without discouraging myself again *and* without going bankrupt. I'm looking support from people who care. It also means getting a lot of non-support from people who non-care. That's a fact of life.

Yes, and obviously I am discouraging you because I think that splitting is not the right thing to do. But its not only that, I want to encourage you to work together on a vague base, which is the CVS and contribution to Millers code. This is not an easy task.

Your problems with money should not be to hard to solve, get yourself a job, your qualifications are excellent, and if you are clever enough you will have enough free time to work on Pd. Thats actually what is the main development model of free software.

...

Miller has always been very open to contributions

Compared to the jMax team, yes...

Compared to the MAX/MSP team, very much... ;-)

However, many other open-source projects are intensely more collaborative than Pd, in such a way that (the core of) Pd, jMax and MAX/MSP look about as collaborative as each other.

A somewhat vague argument. The universe is big, compared to that, a mouse and an elephant are about the same size. There are only few (relevant) open-source project that are that much more collaborative than Pd. Debian might be an example.

It is true that most other projects have better infrastructure and rules about collaboration. That is a point we have to work on.

...

he includes patches when time permits and also explains why he doesn't include others.

I haven't found his explanations to be always particularly explaining, and I don't expect them to always be, but there are some biggies for which his explanations were even more disconcerting than the lack thereof.

I understand that there are several things that one might want to change in Pd, that can't be done. Either you accept it or well, you have to split. You have to decide what is better for you. This doesn't mean that it is better for others.

I don't mean just the patch submission system, I also mean discussions that lead potential patch submitters to decide whether submitting patches is worth doing.

The patch submission system is not specifically good, but it is better than what we had before. We can improve a lot, on the CVS and the patch submission, but someone has to do it, make a good proposal, and get enough people on his/her side.

Günter

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

On Fri, 5 May 2006, Tim Blechmann wrote:

well, especially being an artistic tool, it shouldn't require the user to learn 1001 workarounds for trivial problems,

right, and keeping some features underdeveloped on the grounds that Pd isn't supposed to be a programming language, just fuels the need for workarounds, and it ends up that artists have to figure out the same workarounds as when a programmer is confronted to underdeveloped aspects of a programming language... only that the programmer is better trained at figuring out workarounds.

nor should the user have to worry about obscure message vs. list problems ...

This is a different problem because messages and lists can't be unified without making another problem appear elsewhere. If every message is seen as a list then there is no way left to tell an object to do something special because all possible messages get already seen as data. I've already explained this in great detail on pd-list and/or pd-dev. Think of the "set" method for example.

So I think that in the message-vs-list case, if there are obscure problems, they should be transformed into clear problems by teaching them to every pd user.

There are many other things that could be made simpler without introducing the same amount of new problems (but not all of them can be made so without breaking compatibility).

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

Frank Barknecht wrote: ...

...

So I think that in the message-vs-list case, if there are obscure problems, they should be transformed into clear problems by teaching them to every pd user.

And also to developers: Some of the annoyances with list- vs. "meta"-messages are introduced by externals like those inherited from Max: [prepend] in all or most of its versions except [list prepend] or the zl-family or - in a different way - [OSCroute], because these output a meta-message even when they receive a proper list-message and thus may introduce unwanted side effects later in the processing chain if users aren't aware of this.

hmm... I tried to explain this in another thread. Let me try again:

1. It is probably fair to say that the Pd rules of message typing

are better than the old rules still preserved in Max. Nevertheless, Pd is just as unsuitable for list processing as Max.

2. One of the old rules defines lists as multi-atom messages that

start with a number, and declares that messages starting with a symbol after the 'list' selector are illegal (although Max does not enforce it fully). Therefore, [list] cannot be used in max-compatible patches.

3. Regardless of the rules, [zl]'s and [prepend]'s way of

conversion, i.e. discarding of the 'list' selector of symbolic list messages is just as bad, good, or irrelevant as the [list]'s way of conversion, i.e. prepending of the 'list' selector to non-list messages -- the same bit of information is lost.

4. In nearly all cases when [prepend] is really needed, it is used

for assigning a selector to a message. Inserting [prepend add] before a [textfile] is more natural, than inserting [list prepend add] -> [list trim]. Differentiating a 'list to be stored' from a 'non-list to be stored' requires a [route list] anyway, with either [prepend add list] or [list prepend add list] in one of the branches.

Krzysztof

On May 7, 2006, at 12:10 AM, Frank Barknecht wrote:

Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

...

This is a different problem because messages and lists can't be
unified without making another problem appear elsewhere. If every message
is seen as a list then there is no way left to tell an object to do something special because all possible messages get already seen as data. I've already explained this in great detail on pd-list and/or pd-dev.
Think of the "set" method for example.

So I think that in the message-vs-list case, if there are obscure problems, they should be transformed into clear problems by
teaching them to every pd user.

And also to developers: Some of the annoyances with list- vs. "meta"-messages are introduced by externals like those inherited from Max: [prepend] in all or most of its versions except [list prepend] or the zl-family or - in a different way - [OSCroute], because these output a meta-message even when they receive a proper list-message and thus may introduce unwanted side effects later in the processing chain if users aren't aware of this.

AFAIR Miller's objects all work in something one could call the "list-message domain", which successfully prohibits these side effects from occuring, which makes list-processing a very comfortable thing again. If needed, translating a list-message to a meta-message is trivial, and generally this translation only is needed directly in front of an object when a meta-message is needed to access a method of this object.

I agree that Pd objects should not be clones of max objects in this
situation, and keeping things in the list domain probably makes the
most sense. But Pd is not entirely consistent in this. One key
example for me is that [route list] does not always output a list.
(Yes, I know, sore subject perhaps).

.hc

        "The arc of history bends towards justice."
                                        - Dr. Martin Luther King,  

Jr.

On Apr 25, 2006, at 2:49 PM, derek holzer wrote:

My suggestion would be to make a "dictionary" of objects, maybe sorted by name, library or general function (dataflow, 3d, audio, video, I/O...), such as the directories which were made by the user community for CSound. That might be useful as a PDF or hardcopy even. The PDcyclopia?

This idea garners my unfettered support. I hope this gets implemented at some point. I'm willing to help out.

Would externs in the "unsupported" folder of CVS module "externals" also be included in this compendium ?

./d5

On Apr 25, 2006, at 9:39 PM, day 5 wrote:

On Apr 25, 2006, at 2:49 PM, derek holzer wrote:

...

My suggestion would be to make a "dictionary" of objects, maybe
sorted by name, library or general function (dataflow, 3d, audio,
video, I/O...), such as the directories which were made by the
user community for CSound. That might be useful as a PDF or
hardcopy even. The PDcyclopia?

This idea garners my unfettered support. I hope this gets
implemented at some point. I'm willing to help out.

Would externs in the "unsupported" folder of CVS module "externals"
also be included in this compendium ?

The idea is to have meta data in each help file. Then that data is
parsed by Pd and used to generate a searchable index of all of the
objects. Its been discussed and spec'ed out in the PDDP meetings and
template designs.

.hc

"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism." - retired U.S. Army general,
William Odom

On Wed, 26 Apr 2006, day 5 wrote:

Perhaps an idea might be an API function to Pd that scans the user's Pd externals directory (on *nix nominally /usr/local/lib/pd/extra) and dumps a list of all main_ symbols found to the Pd window or the stdout... similar to how users can access GridFlow's "profiler_dump" via a menu; Something like "Help" -> "Dump Externals List".

There's already that in DesireData, but it's not dumping to the pd window; instead it's powering the class browser and the completions. Also, it puts everything together: classes already loaded, externals (singles), and abstractions. It honors the -path directives, but I don't think that it would find a file of the form blah/blah.pd_linux as [blah] (contrary to -lib).

I don't know why it would pick up "main_" symbols though. I don't know what those would be. In a program there's a symbol "main" (or "_main" in MSDOS and OSX). However there is not such a thing in libraries. You might be meaning "blah_setup" but it's not like you can get any info about the class by looking at that symbol...

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

I'll be at Ars Electronica, but I could do a meeting Sept 8th or later.

.hc

On Aug 26, 2006, at 1:46 PM, B. Bogart wrote:

wow, this is an old email.

Derek, Basically what your talking about is covered by the features of the meta-data in a PD help patch. Then in pd we can generate a list of all the installed (and loadable) objects. We can also search by
keyword in the description or keywords feilds, like "symbol". I think doing
this in PD is the best thing to do. As for searching for them that are not installed something similar could run in CVS and have a web-front-end.

How are people for a PDDP meeting next week? I'll probably be busy on the 29th and 30th, and Sept 1st, but otherwise free.

The index file with all the meta-data for all objects could be made pretty and printable... if someone ends up making a script that PS's a PD patch we could also use that stuff to generate a PDF with a
thumbnail of the reference patch.

.b.

derek holzer wrote:

...

Hi HC, Adam,

Hans-Christoph Steiner wrote:

...

I am not opposed to things like PDB or ways of searching for
existing objects. But if you are going to learn the object, functional examples work best. But a manual would not be a good way to search for objects.

In general, I don't really agree that a manual with pictures of
patches would be very useful. The functionality to learn and experiment by changing things really isn't there.

OTOH, one thing that people in my workshops are always asking for
is a list of all the objects, including the externals. There isn't
really one place to get all this, except online with the PDB, but that's not
a good reference when you don't have any net access. I tried maintaining
a text file with as many as I could, but it's very incomplete.

My suggestion would be to make a "dictionary" of objects, maybe
sorted by name, library or general function (dataflow, 3d, audio, video, I/O...), such as the directories which were made by the user
community for CSound. That might be useful as a PDF or hardcopy even. The
PDcyclopia?

d.

As I always say, I am not going to stop anyone from working on any
aspect of Pd however they see fit (of course, as long as it doesn't
interfere with the work of others).

I like reading too, but I think if we are teaching an interactive
programming language, you can explain things really well with an
example, where the same thing would take pages of text. No one is
proposing that there should be no text, there will be lots of text.
But the core idea is that _every_ idea is illustrated with a
_functional_ example. Why settle for a static image of a patch when
you can easily have a working one with the text?

Plus, it would be very easy to make a PDF from the Pd manual.

.hc

On Apr 20, 2006, at 7:40 PM, David Powers wrote:

I STRONGLY disagree with having a manual that is ONLY pd patches --
unless those patches are translated into PDF or HTML also.

Maybe I'm old fashioned, but I always print important reference
material out onto notebooks, and I often do programming with paper
and pencil. So, I'd first of all worry that a pd patch might
require interactivity to fully understand what is happening. So, at
a minimum, all patches should include enough text to understand the
information, even if the patch isn't running.

Also, sometimes I reference things on work computers where I don't
have pd. And, on Windows, many things still crash pd. There is
nothing more annoying than being in the middle of studying things
and suddenly having everything shut down and having to load it all
up again.

So, I feel that a "manual" worthy of the name should allow one to
access the information, regardless of having pd running or not.
Perhaps the patches could just be converted to PDF, and somehow a
page index created.

I LIKE "book learning", I often learn best that way--I have made
many good pd patches and python programs riding the bus or train
many times. In fact, I find that when I plan with pen and paper, my
pd patches come out much better, and it's very helpful to have
traditional reference materials when working in this way. Does
everyone really have a problem with making a traditional manual for
pd?

~David

On 4/19/06, Hans-Christoph Steiner hans@eds.org wrote:

Is Adam Hyde on the list? I think its great for anyone to join, seriously, the more the merrier. Already, the intro that I have been assembling is drawing on the work of 10 or so people.

We discussed the idea of a manual a fair amount in the PDDP meetings. I think most/all of us agreed that we want to try to make a Pd manual that is completely made up of Pd patches. The point is to highlight learning thru example for every single step. Having a separate manual seems to highlight the book learning style more. Yes, this will mean a lot of patches. I already have 60-ish for the intro.

But I also just made a pager object which allows you to easily navigate the pages like a manual. Its included in the most recent test releases:

http://at.or.at/hans/pd/installers.html

Go to Help->Browser... then manuals/intro and load 0-pager.pd I tested it on Windows and Mac OS X.

.hc

On Apr 19, 2006, at 5:07 PM, derek holzer wrote:

...

Hey HC and the gang,

Adam Hyde has been working on a PDF/HTML manual for getting PD up and running. I've talked with him a bit about how beneficial such a thing is versus a set of patches like the ones which have been contributed here. But you might want to have a look at it:

http://www.flossmanuals.net/edit

I may be meeting with him soon about where it could go, and I'm sure he's open for other suggestions as well.

Mark Polishook wrote:

...

Two comments: 1. the patches are very good at identifying core concepts and explaining them. 2. But the hard thing about tutorial writing is it's difficult to show how those small concepts relate to larger artistic concerns.

I agree on both fronts. The main issue with PD is that people use it for so many different things that demonstrating "artistic concerns" would be pretty limited to what the author happens to be doing with PD. All the same, I do find that there is a serious lack of "demo" patches, or something like a "user library" that noobs could have a look at for inspiration. Simple and not so simple but usable tools, along the same lines as the User Library in Reaktor, or maybe even the Pluggo patches from Cycling74 (except you can't open those up, can you???). I tried to make something like that with ParticleChamber, and I know that other stuff has come up on the list when people ask about synth collections and the like. Might be good to try to collect these kinds of abstractions together into a library of sorts (a la RRRAD).

best, derek

-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 76: "Give the game away"

---

__ ____

As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

As we enjoy great advantages from inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. - Benjamin Franklin