A false dichotomy is made between abstractions and externals. Also there are many externals that don't include abstractions but are nonetheless compatible with Pd vanilla.
"word or symbol" creates a false dichotomy.
Also: it isn't made clear what is special about list messages as opposed to, say, blueberry messages, which I define as starting with the word blueberry followed by zero or more atoms*.
On Fri, 11 Feb 2011, Jonathan Wilkes wrote:
A false dichotomy is made between abstractions and externals.
Such a false dichotomy is also used on the front page of http://puredata.info/ :
« It is easy to extend Pd by writing object classes ("externals") or patches ("abstractions"). »
I say that even though at the implementation level, abstractions aren't classes, for the user, it works like a class.
Also there are many externals that don't include abstractions but are nonetheless compatible with Pd vanilla.
What part of the text are you referring to, in particular ?
BTW, http://en.flossmanuals.net/PureData/Abstractions talks about "external patches", but given how "external" is being overwhelmingly used with a totally different meaning in Pd. (are newbies supposed to have to guess ?)
"word or symbol" creates a false dichotomy.
what about the occurrence of "selector-word" in the Messages page ?
Also: it isn't made clear what is special about list messages as opposed to, say, blueberry messages, which I define as starting with the word blueberry followed by zero or more atoms*.
mmm, blueberries. :)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Once again, I(we've discussed this before) it seems that there is an urgent name/concept-convention need.
Just brainstorming, but a nice exercise would be:
concept meaning dev user some thoughts abstraction ? ? ? (seems the most easy one) class ? ? ? (should be a class definition?) object ? ? ? (corresponds to a visual object in the gui? no matter if it is external or abstraction?) external ? ? ? (seems easy too)
best regards, Pedro
On Sun, Feb 13, 2011 at 4:46 PM, Mathieu Bouchard matju@artengine.cawrote:
On Fri, 11 Feb 2011, Jonathan Wilkes wrote:
A false dichotomy is made between abstractions and externals.
Such a false dichotomy is also used on the front page of http://puredata.info/ :
« It is easy to extend Pd by writing object classes ("externals") or patches ("abstractions"). »
I say that even though at the implementation level, abstractions aren't classes, for the user, it works like a class.
Also there are many externals that don't include abstractions but are nonetheless compatible with Pd vanilla.
What part of the text are you referring to, in particular ?
BTW, http://en.flossmanuals.net/PureData/Abstractions talks about "external patches", but given how "external" is being overwhelmingly used with a totally different meaning in Pd. (are newbies supposed to have to guess ?)
"word or symbol" creates a false dichotomy.
what about the occurrence of "selector-word" in the Messages page ?
Also: it isn't made clear what is special about list messages as opposed
to, say, blueberry messages, which I define as starting with the word blueberry followed by zero or more atoms*.
mmm, blueberries. :)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 13 Feb 2011, Pedro Lopes wrote:
Once again, I(we've discussed this before) it seems that there is an urgent name/concept-convention need. Just brainstorming, but a nice exercise would be:
Could you please explain how this table ought to be filled ? That is, explain the meaning of the columns... What should go in the 'dev' and 'user' columns that shouldn't go in the 'meaning' column, and what should go in the 'dev' column that should go in the 'user' column, and/or vice-versa ?
concept meaning dev user some thoughts abstraction ? ? ? (seems the most easy one) class ? ? ? (should be a class definition?) object ? ? ? (corresponds to a visual object in the gui? no matter if it is external or abstraction?) external ? ? ? (seems easy too)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Sun, 2/13/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@eds.org, pd-list@iem.at Date: Sunday, February 13, 2011, 5:46 PM On Fri, 11 Feb 2011, Jonathan Wilkes wrote:
A false dichotomy is made between abstractions and
externals.
Such a false dichotomy is also used on the front page of http://puredata.info/ :
« It is easy to extend Pd by writing object classes ("externals") or patches ("abstractions"). »
As well as in svn, where, for example, list-abs is in the abstractions folder, but there are plenty of libraries in "externals" that are made up only of abstractions.
I say that even though at the implementation level, abstractions aren't classes, for the user, it works like a class.
Also there are many externals that don't include
abstractions but are nonetheless compatible with Pd vanilla.
What part of the text are you referring to, in particular ?
The last sentence states that list-abs "doesn't require any externals so that it is compatible with vanilla Pd as well".
BTW, http://en.flossmanuals.net/PureData/Abstractions talks about "external patches", but given how "external" is being overwhelmingly used with a totally different meaning in Pd. (are newbies supposed to have to guess ?)
"word or symbol" creates a false dichotomy.
what about the occurrence of "selector-word" in the Messages page ?
Yep, that, too.
Also: it isn't made clear what is special about list
messages as opposed to, say, blueberry messages, which I define as starting with the word blueberry followed by zero or more atoms*.
mmm, blueberries. :)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sun, 13 Feb 2011, Jonathan Wilkes wrote:
As well as in svn, where, for example, list-abs is in the abstractions folder, but there are plenty of libraries in "externals" that are made up only of abstractions.
That might because it's forbidden for any externals to be in the abstractions folder. I once tried to include 1 % of C code in an abstractions library I had put in abstractions/ , and was told I had to move it out. Preventively, people can put abstractions libraries in externals/ so that they never have to move them.
Does that seem like an accurate hypothesis ?
What else would be a reason to put those libraries in externals/ ?
I say that even though at the implementation level, abstractions aren't classes, for the user, it works like a class. Also there are many externals that don't include abstractions but are nonetheless compatible with Pd vanilla.
What part of the text are you referring to, in particular ?
The last sentence states that list-abs "doesn't require any externals so that it is compatible with vanilla Pd as well".
Yeah, that's nonsense. Pd-vanilla is the origin of the <m_pd.h> interface for making externals.
The idea of Vanilla-without-externals is probably most useful to ZenGarden users, who can't compile any existing externals, because ZenGarden was designed to be incompatible with Pd-Vanilla. It is because of this incompatibility, that Zengarden users are led to excessively focus on what's compatible with Vanilla-without-Externals, because that's all that the ZenGarden project aims to support.
Just another hypothesis. What do you think ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Tue, 2/15/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@eds.org, pd-list@iem.at Date: Tuesday, February 15, 2011, 7:19 PM On Sun, 13 Feb 2011, Jonathan Wilkes wrote:
As well as in svn, where, for example, list-abs is in
the abstractions folder, but there are plenty of libraries in "externals" that are made up only of abstractions.
That might because it's forbidden for any externals to be in the abstractions folder. I once tried to include 1 % of C code in an abstractions library I had put in abstractions/ , and was told I had to move it out. Preventively, people can put abstractions libraries in externals/ so that they never have to move them.
Does that seem like an accurate hypothesis ?
Yes.
What else would be a reason to put those libraries in externals/ ?
I say that even though at the implementation
level, abstractions aren't classes, for the user, it works like a class. Also there are many externals that don't include abstractions but are nonetheless compatible with Pd vanilla.
What part of the text are you referring to, in
particular ?
The last sentence states that list-abs "doesn't
require any externals so that it is compatible with vanilla Pd as well".
Yeah, that's nonsense. Pd-vanilla is the origin of the <m_pd.h> interface for making externals.
Btw-- the manual makes a distinction between "abstractions" and "externs".
The idea of Vanilla-without-externals is probably most useful to ZenGarden users, who can't compile any existing externals, because ZenGarden was designed to be incompatible with Pd-Vanilla. It is because of this incompatibility, that Zengarden users are led to excessively focus on what's compatible with Vanilla-without-Externals, because that's all that the ZenGarden project aims to support.
Just another hypothesis. What do you think ?
I think it's useful to people doing stuff with audio who want to learn Pd without being surrounded by a haze of thousands of possibly useful, possibly buggy, poorly documented object classes that may or may not be usable for someone on a different machine. The danger, however, is that one can end up arbitrarily limiting the types of projects one does to a narrow subset that fit the types of tools available with "Pd-minus-externals"*. Then again maybe the limited set of tools is what attracts that user in the first place...
- "Puritan Data"?
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, 15 Feb 2011, Jonathan Wilkes wrote:
--- On Tue, 2/15/11, Mathieu Bouchard matju@artengine.ca wrote:
Yeah, that's nonsense. Pd-vanilla is the origin of the <m_pd.h> interface for making externals.
Btw-- the manual makes a distinction between "abstractions" and "externs".
It needs to, at least a bit, because they have a different loading priority : *.pd is not sought for at the same time as *.pd_linux, for example.
I think it's useful to people doing stuff with audio who want to learn Pd without being surrounded by a haze of thousands of possibly useful, possibly buggy, poorly documented object classes that may or may not be usable for someone on a different machine.
If you thought Pd-Vanilla was that well documented to start with, you wouldn't be maintaining a separate set of help files.
How can those classes affect those users ? I mean, how can the collection of pd-extended classes act like a haze, when the users don't look at a list of 2000 classes ?
- "Puritan Data"?
I could be joking but I don't feel like it.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Wed, 2/16/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@eds.org, pd-list@iem.at Date: Wednesday, February 16, 2011, 5:28 AM On Tue, 15 Feb 2011, Jonathan Wilkes wrote:
--- On Tue, 2/15/11, Mathieu Bouchard matju@artengine.ca
wrote:
Yeah, that's nonsense. Pd-vanilla is the origin of
the
<m_pd.h> interface for making externals.
Btw-- the manual makes a distinction between
"abstractions" and "externs".
It needs to, at least a bit, because they have a different loading priority : *.pd is not sought for at the same time as *.pd_linux, for example.
I don't understand this process. I understand the order, but why, for example, does
[./sigmund~] create an instance of the sigmund~ class? (Pd version 0.43.0-extended-20110205, only tested it on winxp)
I think it's useful to people doing stuff with audio
who want to learn Pd without being surrounded by a haze of thousands of possibly useful, possibly buggy, poorly documented object classes that may or may not be usable for someone on a different machine.
If you thought Pd-Vanilla was that well documented to start with, you wouldn't be maintaining a separate set of help files.
We Appreciate Your Feedback. Please Rate Our Performance on the matju Scale:
[] Poor [] Unimpeachable
The old Pd internal docs are decent-- on the whole they contain the
information that you'd want to know about inlets, outlets, and args.
I found they lacked in the following areas:
- standard format ("I know the args are listed in one of these paragraphs,
but I can't remember which one")
- related objects (still working on that one)
- related topics/tutorials
- one-click links to other relevant docs (or the manual!)
- array name conflicts when more than one help patch is open
- errata that never seemed to get addressed
- a few missing/orphaned help patches
Looking over the externals, on the other hand, I see:
- massive lack of example patches (not to mention _clear_ examples)
- lots of missing help patches
Those two alone are the biggest problems that drag down the quality of the external help docs as a whole, but there are also:
- unexplained args, xlets
- some abandoned objects that crash Pd, help patches that freeze Pd
- prototype or expirimental objects not labeled as such
- stop gap help patches with no content
- incorrect terminology (referring to an anything as a list)
- dependence on order in which connections were made for trigger order
in example patches
- attempts to automate the creation of help patches, apparently without
opening any of them and noticing it didn't work
- EVERYTHING from the first list missing for lost of externals, too
How can those classes affect those users ? I mean, how can the collection of pd-extended classes act like a haze, when the users don't look at a list of 2000 classes ?
Well if you use Pd Vanilla and want to find an object that does something, you look for it, find it (or not), and start using it.
If you use Pd Extended you do the same thing, but then maybe the object you were using isn't in the next release because nobody is maintaining it, or you thought that object was an internal but it isn't*, or there are 5 different objects with 5 different interfaces to do the same thing surrounding you like a hall of mirrors, and you need to do some work to check out which ones are the most likely to continue to be maintained, and which ones are merely an illusion...
Also, keep in mind that currently it's hard to ask Pd Extended to show you all the externals that do the thing you want to do, and get back a meaningful answer.
- and of course you right-click to see what library it is actually in but
Pd's search party comes back with very bad news: "Sorry, ma'am, but your child never even existed..."
- "Puritan Data"?
I could be joking but I don't feel like it.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 16 Feb 2011, Jonathan Wilkes wrote:
I don't understand this process. I understand the order, but why, for example, does [./sigmund~] create an instance of the sigmund~ class?
It's not like shell commands : even relative names that contain slashes are looked for in the -path. In that sense, it's more like gcc's -I options (including C_INCLUDE_PATH, CPLUS_INCLUDE_PATH and the implicit /usr/include and stuff).
How can those classes affect those users ? I mean, how can the collection of pd-extended classes act like a haze, when the users don't look at a list of 2000 classes ?
Well if you use Pd Vanilla and want to find an object that does something, you look for it, find it (or not), and start using it.
But I mean, if you look at Miller's index while in Pd-extended, you only see the list of the classes that are in Vanilla. It's not like the 2345 other classes are actively bugging you in this context. It's a completely different game than going in the "5.reference" folder. You don't need to install Vanilla to benefit from Miller's help files.
Also, keep in mind that currently it's hard to ask Pd Extended to show you all the externals that do the thing you want to do, and get back a meaningful answer.
You mean you can ask it...? (you mean 43 ?)
- and of course you right-click to see what library it is actually in
but Pd's search party comes back with very bad news: "Sorry, ma'am, but your child never even existed..."
Which error message do you actually mean ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Sun, 2/20/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@eds.org, pd-list@iem.at Date: Sunday, February 20, 2011, 11:31 PM On Wed, 16 Feb 2011, Jonathan Wilkes wrote:
I don't understand this process. I understand
the order, but why, for
example, does [./sigmund~] create an instance of the sigmund~
class?
It's not like shell commands : even relative names that contain slashes are looked for in the -path. In that sense, it's more like gcc's -I options (including C_INCLUDE_PATH, CPLUS_INCLUDE_PATH and the implicit /usr/include and stuff).
I'm only familiar with the shell usage. I'm having trouble seeing the benefit of how Pd does it-- seems like it renders "./" pretty much meaningless, and "../" means "search the parent directory of every dir in the path", which seems like something one would rarely do. Am I misunderstanding something?
How can those classes affect those users ? I
mean, how can
the collection of pd-extended classes act like a
haze, when
the users don't look at a list of 2000 classes ?
Well if you use Pd Vanilla and want to find an object
that does something,
you look for it, find it (or not), and start using
it.
But I mean, if you look at Miller's index while in Pd-extended, you only see the list of the classes that are in Vanilla. It's not like the 2345 other classes are actively bugging you in this context. It's a completely different game than going in the "5.reference" folder. You don't need to install Vanilla to benefit from Miller's help files.
Also, keep in mind that currently it's hard to ask Pd
Extended
to show you all the externals that do the thing you
want to do, and get
back a meaningful answer.
You mean you can ask it...? (you mean 43 ?)
- and of course you right-click to see what library it
is actually in but Pd's search party comes back with very bad news: "Sorry, ma'am, but your child never even existed..."
Which error message do you actually mean ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, Feb 15, 2011 at 03:09:35PM -0800, Jonathan Wilkes wrote:
--- On Tue, 2/15/11, Mathieu Bouchard matju@artengine.ca wrote:
The idea of Vanilla-without-externals is probably most useful to ZenGarden users, who can't compile any existing externals, because ZenGarden was designed to be incompatible with Pd-Vanilla. It is because of this incompatibility, that Zengarden users are led to excessively focus on what's compatible with Vanilla-without-Externals, because that's all that the ZenGarden project aims to support.
Just another hypothesis. What do you think ?
I think it's useful to people doing stuff with audio who want to learn Pd without being surrounded by a haze of thousands of possibly useful, possibly buggy, poorly documented object classes that may or may not be usable for someone on a different machine. The danger, however, is that one can end up arbitrarily limiting the types of projects one does to a narrow subset that fit the types of tools available with "Pd-minus-externals"*. Then again maybe the limited set of tools is what attracts that user in the first place...
I think, Matju may be overestimating the number of Zengarden users a bit, but as ZG was started by an RjDj developer, maybe he meant to refer to RjDj in general.
With RjDj the main motivation for restricting the number of included object classes to those in Pd vanilla (plus a few) was to provide a standard working platform for musicians and listeners that is long-term maintainable on limited hardware and limiting operating systems.
Pd-extended was ruled out, because it does (or did) not provide a suitable level of standardization: The libraries in Pd-extended have a lot of overlapping functionality, because they were just "thrown together" from what's in the SVN repository. Many make no sense in the RjDj context anyway and all in all having to package and distribute and keeping up to date such a large package is a maintaince nightmare. (It's also a legal nightmare in Apple's AppStore, but that's a different story.)
So RjDj deliberatly restricted itself to vanilla (and not deliberatly had to throw out [expr] because the lawyers said so). The rj abstraction library makes using vanilla a bit easier, but it's not directly part of RjDj, it's just something you put into your patch directory.
Pd vanilla has a stable set of objectclasses of generally good quality, they are tried and true and we have found them to be close to industry strength.
But most importantly Pd vanilla in reality is the only thing that can be called a "standard" set of object classes - it's the only real "standard library" the Pd community has been able (or been forced) to agree on in the many years I'm using Pd. This may be of no importance to people writing Pd patches for their own single laptop, where they can re-install missing objects quickly.
But it's absolutely crucial if your goal is to distribute the patches to hundreds of thousands of iPod/iPhone/... users, as RjDj does for about to years now.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Tue, 15 Feb 2011 13:19:35 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
The idea of Vanilla-without-externals is probably most useful to ZenGarden users, who can't compile any existing externals, because ZenGarden was designed to be incompatible with Pd-Vanilla. It is because of this incompatibility, that Zengarden users are led to excessively focus on what's compatible with Vanilla-without-Externals, because that's all that the ZenGarden project aims to support.
Just another hypothesis. What do you think ?
I think you're right. This minimal set of features is designed from the outset. Martin and I spent some afternoons in the park discussing the idea of an axiomatic set of DSP operations, from which all other patches can be built. He was quite clear on that as a goal from the start. The sensitivity of sound to small changes in implementation has been on my mind from the start, so if you like the emphasis was on a reliably portable functional equivalence without code compatability. I have always taken this, perhaps presumptuously, as one of Miller's strong principles. Without it the slogan "The diagram is the program" fails, and one cannot use Pd to write books, teach or otherwise share datafow programs in a purely visual way. The commercial advantages too, as the RjDj project benefitted from and upheld, are ease of maintenance and widespread compatability across diverse hardware.
Pd-Extended and the ecology of externals is an overlapping but different space, marvelous in its own ways, but for projects like defining a portable markup standard for reactive music, or creating a new standard "middle layer" in game audio, then the more robust and limited the basic unit gen set is the better.
Andy
On Wed, 16 Feb 2011, Andy Farnell wrote:
The sensitivity of sound to small changes in implementation has been on my mind from the start, so if you like the emphasis was on a reliably portable functional equivalence without code compatability. I have always taken this, perhaps presumptuously, as one of Miller's strong principles. Without it the slogan "The diagram is the program" fails,
When I came up with that slogan, I wasn't thinking about portability nor functional equivalence, and I still don't see how they are related.
Even though portability is nice and functional equivalence is also nice.
« The diagram is the program » only meant that unlike other dataflow diagrams that people may have seen in the context of software engineering, those pd diagrams are source code that can be run as-is. I came up with the sentence while trying to explain pd, because I showed a pd patch and the other person didn't realise that it was not a form of high-level documentation for something else.
and one cannot use Pd to write books, teach or otherwise share datafow programs in a purely visual way.
I'm following even less...
The commercial advantages too, as the RjDj project benefitted from and upheld, are ease of maintenance and widespread compatability across diverse hardware.
Is RjDj using ZenGarden, or LibPd, or both ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 16 Feb 2011 15:44:02 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
On Wed, 16 Feb 2011, Andy Farnell wrote:
principles. Without it the slogan "The diagram is the program" fails,
When I came up with that slogan, I wasn't thinking about portability nor functional equivalence, and I still don't see how they are related.
They are related above in that they were both goals of ZenGarden.
« The diagram is the program » only meant that unlike other dataflow
It is the word "only" here that puzzles me Mathieu. Please don't undervalue that slogan (and I apologise if I misattributed it), it is astute if not profound to recognise a one to one correspondence between the image and the logic. In interpreting it further one might say "The diagram is the sound", at least that has been my hope for what is to be taken as an appeal to a visual markup for sound in "Designing Sound" *. So far it seems to have worked out well.
*(Of course some data elements do get hidden, initial states maybe..)
and one cannot use Pd to write books, teach or otherwise share dataflow programs in a purely visual way.
I'm following even less...
Not sure how to help, because not sure where you fell off there. Seems obvious to me that where a picture captures a sound in its entirety it is a powerful pedagogical device. By "purely" I meant sole/only way.
The commercial advantages too, as the RjDj project benefited from and upheld, are ease of maintenance and widespread compatibility across diverse hardware.
Is RjDj using ZenGarden, or LibPd, or both ?
Actually neither right now, tis Miller Vanilla with a little extra goodness by Amaury Hazan and Paul Brossier to make it work on those nasty iThings. Though what we call RjDj as a product rather than software base is now in its adolescence and may assume new forms with ZenGarden and/or LibPd and/or other frameworks AFAIK. You need to ask Martin Roth who is now in the captains seat for technology there.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
best, andy
On Wed, 16 Feb 2011, Andy Farnell wrote:
On Wed, 16 Feb 2011 15:44:02 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
On Wed, 16 Feb 2011, Andy Farnell wrote:
principles. Without it the slogan "The diagram is the program" fails,
When I came up with that slogan, I wasn't thinking about portability nor functional equivalence, and I still don't see how they are related.
They are related above in that they were both goals of ZenGarden.
... I mean how they are related to the slogan. I say that because you connected them to the slogan.
« The diagram is the program » only meant that unlike other dataflow
It is the word "only" here that puzzles me Mathieu. Please don't undervalue that slogan (and I apologise if I misattributed it), it is astute if not profound to recognise a one to one correspondence between the image and the logic.
I don't see how the sentence « those diagrams are source code » doesn't say that there's (almost) a one-to-one correspondence.
But the one-to-one correspondence isn't exact. I could make a list of ways in which it isn't. Nevertheless, with a little care, a screenshot can be made in a way that can be read by someone that can repatch it if the .pd file itself has not been published.
Now, what does it have to do with portability and with functional equivalence of multiple implementations of pd ?
In interpreting it further one might say "The diagram is the sound", at least that has been my hope for what is to be taken as an appeal to a visual markup for sound in "Designing Sound" *. So far it seems to have worked out well.
When you say "the diagram is the sound", what do you make of all those patches that interactively produce sound, and thus can't be directly thought to be the sound, but instead, to be a relationship between the input and the sound ?
and one cannot use Pd to write books, teach or otherwise share dataflow programs in a purely visual way.
I'm following even less...
Not sure how to help, because not sure where you fell off there. Seems obvious to me that where a picture captures a sound in its entirety it is a powerful pedagogical device. By "purely" I meant sole/only way.
It's that at that point the sentence still seems to be about portability and functional equivalence. How are they necessary to prevent the slogan from failing, and to make Pd usable to write books, etc. ?
Actually neither right now, tis Miller Vanilla with a little extra goodness by Amaury Hazan and Paul Brossier to make it work on those nasty iThings. Though what we call RjDj as a product rather than software base is now in its adolescence and may assume new forms with ZenGarden and/or LibPd and/or other frameworks AFAIK. You need to ask Martin Roth who is now in the captains seat for technology there.
Ok, thanks.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 16 Feb 2011 16:55:24 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
I don't see how the sentence « those diagrams are source code » doesn't say that there's (almost) a one-to-one correspondence.
Yikes, I tried running that through De Morgans What is it you _do_ see there? Or does the law of the excluded middle prevent us from straying there? :)
But the one-to-one correspondence isn't exact. I could make a list of ways in which it isn't.
Please, a list I'd like to see out of curiosity when you have a mo. I thought about that long and hard, mainly it was things like ambiguous connections where filaments cross over another object inlet, or horror of horrors, identical objects copied on top of each other and wired in place...I've been caught out that way before.
Nevertheless, with a little care, a screenshot can be made in a way that can be read by someone that can repatch it if the .pd file itself has not been published.
I'll be honest it took a _lot_ of care. Out of well over 1000 diagrams one or two ambiguities have raised peoples annoyance enough to email me a "complaint". That's quite a good record I think, but I spent many hours re-arranging objects and coords to get clear and unambiguous patches. What some recognise as my style now was heavily influenced by the writing and the need to have patches unambiguously read by eyes other than my own.
Now, what does it have to do with portability and with functional equivalence of multiple implementations of pd ?
In interpreting it further one might say "The diagram is the sound", at least that has been my hope for what is to be taken as an appeal to a visual markup for sound in "Designing Sound" *. So far it seems to have worked out well.
When you say "the diagram is the sound", what do you make of all those patches that interactively produce sound, and thus can't be directly thought to be the sound, but instead, to be a relationship between the input and the sound ?
Exactly as you say so succinctly, these are potential sounds, without the necessary performance parameters, ergo the relation between a parameter set and realised sounds. This is what I call deferred form, or for Rocchesso & Polotti, an unrealised sounding object. Indeed, I define that as one of the essential arts of procedural audio, the understanding of potentiality.
and one cannot use Pd to write books, teach or otherwise share dataflow programs in a purely visual way.
I'm following even less...
Not sure how to help, because not sure where you fell off there. Seems obvious to me that where a picture captures a sound in its entirety it is a powerful pedagogical device. By "purely" I meant sole/only way.
It's that at that point the sentence still seems to be about portability and functional equivalence. How are they necessary to prevent the slogan from failing, and to make Pd usable to write books, etc. ?
Teaching requires clear, undistorted communication. If that communication fails, because the machine or the interpreter does not convey your intentions to the student, then the lesson fails. You could still keep part of your slogan, perhaps modify it to "The diagram is a program". Just maybe not the same program as mine.
best,
a.
Actually neither right now, tis Miller Vanilla with a little extra goodness by Amaury Hazan and Paul Brossier to make it work on those nasty iThings. Though what we call RjDj as a product rather than software base is now in its adolescence and may assume new forms with ZenGarden and/or LibPd and/or other frameworks AFAIK. You need to ask Martin Roth who is now in the captains seat for technology there.
Ok, thanks.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Thu, 2/17/11, Andy Farnell padawan12@obiwannabe.co.uk wrote:
From: Andy Farnell padawan12@obiwannabe.co.uk Subject: Re: [PD] FLOSS book Lists chapter To: "Mathieu Bouchard" matju@artengine.ca Cc: pd-list@iem.at Date: Thursday, February 17, 2011, 1:24 AM
On Wed, 16 Feb 2011 16:55:24 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
I don't see how the sentence « those diagrams are
source code » doesn't
say that there's (almost) a one-to-one
correspondence.
Yikes, I tried running that through De Morgans What is it you _do_ see there? Or does the law of the excluded middle prevent us from straying there? :)
But the one-to-one correspondence isn't exact. I could
make a list of ways
in which it isn't.
Please, a list I'd like to see out of curiosity when you have a mo. I thought about that long and hard, mainly it was things like ambiguous connections where filaments cross over another object inlet, or horror of horrors, identical objects copied on top of each other and wired in place...I've been caught out that way before.
Nevertheless, with a little care, a screenshot can be
made in a way that can be read by someone that can
repatch it if the .pd
file itself has not been published.
I'll be honest it took a _lot_ of care. Out of well over 1000 diagrams one or two ambiguities have raised peoples annoyance enough to email me a "complaint". That's quite a good record I think, but I spent many hours re-arranging objects and coords to get clear and unambiguous patches. What some recognise as my style now was heavily influenced by the writing and the need to have patches unambiguously read by eyes other than my own.
1 Don't have wires overlapping object boxes, object xlets, or object text* 2 Avoid horizontal wires
What else is there?
-Jonathan
On Wed, 16 Feb 2011, Jonathan Wilkes wrote:
1 Don't have wires overlapping object boxes, object xlets, or object text* 2 Avoid horizontal wires What else is there?
What's the problem with horizontal wires ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Feb 16, 2011, at 8:27 PM, Jonathan Wilkes wrote:
--- On Thu, 2/17/11, Andy Farnell padawan12@obiwannabe.co.uk wrote:
From: Andy Farnell padawan12@obiwannabe.co.uk Subject: Re: [PD] FLOSS book Lists chapter To: "Mathieu Bouchard" matju@artengine.ca Cc: pd-list@iem.at Date: Thursday, February 17, 2011, 1:24 AM
On Wed, 16 Feb 2011 16:55:24 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
I don't see how the sentence « those diagrams are
source code » doesn't
say that there's (almost) a one-to-one
correspondence.
Yikes, I tried running that through De Morgans What is it you _do_ see there? Or does the law of the excluded middle prevent us from straying there? :)
But the one-to-one correspondence isn't exact. I could
make a list of ways
in which it isn't.
Please, a list I'd like to see out of curiosity when you have a mo. I thought about that long and hard, mainly it was things like ambiguous connections where filaments cross over another object inlet, or horror of horrors, identical objects copied on top of each other and wired in place...I've been caught out that way before.
Nevertheless, with a little care, a screenshot can be
made in a way that can be read by someone that can
repatch it if the .pd
file itself has not been published.
I'll be honest it took a _lot_ of care. Out of well over 1000 diagrams one or two ambiguities have raised peoples annoyance enough to email me a "complaint". That's quite a good record I think, but I spent many hours re-arranging objects and coords to get clear and unambiguous patches. What some recognise as my style now was heavily influenced by the writing and the need to have patches unambiguously read by eyes other than my own.
1 Don't have wires overlapping object boxes, object xlets, or object
text* 2 Avoid horizontal wiresWhat else is there?
-Jonathan
- good layout to represent the flow of the data
- encapsulation into rational chunks
- and more...
.hc
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
--- On Sat, 2/19/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] FLOSS book Lists chapter To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, "Andy Farnell" padawan12@obiwannabe.co.uk, pd-list@iem.at Date: Saturday, February 19, 2011, 12:53 AM
On Feb 16, 2011, at 8:27 PM, Jonathan Wilkes wrote:
--- On Thu, 2/17/11, Andy Farnell padawan12@obiwannabe.co.uk
wrote:
From: Andy Farnell padawan12@obiwannabe.co.uk Subject: Re: [PD] FLOSS book Lists chapter To: "Mathieu Bouchard" matju@artengine.ca Cc: pd-list@iem.at Date: Thursday, February 17, 2011, 1:24 AM
On Wed, 16 Feb 2011 16:55:24 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
I don't see how the sentence « those diagrams
are
source code » doesn't
say that there's (almost) a one-to-one
correspondence.
Yikes, I tried running that through De Morgans What is it you _do_ see there? Or does the law of
the
excluded middle prevent us from straying there? :)
But the one-to-one correspondence isn't exact.
I could
make a list of ways
in which it isn't.
Please, a list I'd like to see out of curiosity
when you
have a mo. I thought about that long and hard, mainly it was
things
like ambiguous connections where filaments cross over
another
object inlet, or horror of horrors, identical
objects
copied on top of each other and wired in place...I've
been caught
out that way before.
Nevertheless, with a little care, a screenshot
can be
made in a way that can be read by someone that
can
repatch it if the .pd
file itself has not been published.
I'll be honest it took a _lot_ of care. Out of
well over
1000 diagrams one or two ambiguities have raised peoples
annoyance enough
to email me a "complaint". That's quite a good record I
think, but I
spent many hours re-arranging objects and coords to get
clear and
unambiguous patches. What some recognise as my style now was
heavily
influenced by the writing and the need to have patches
unambiguously read
by eyes other than my own.
1 Don't have wires overlapping object boxes, object
xlets, or object
text* 2 Avoid horizontal wires
What else is there?
-Jonathan
- good layout to represent the flow of the data
- encapsulation into rational chunks
- and more...
That's all true. I guess I'm limiting it to unwanted ambiguities that
_cannot_ be resolved by looking at the patch. So things like fanouts
and [r] creation order wouldn't count as long as having a different
connection/creation order doesn't upset the function of the patch.
.hc
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
On Fri, 18 Feb 2011, Jonathan Wilkes wrote:
That's all true. I guess I'm limiting it to unwanted ambiguities that _cannot_ be resolved by looking at the patch. So things like fanouts and [r] creation order wouldn't count as long as having a different connection/creation order doesn't upset the function of the patch.
When I wrote them, I didn't want to say that they are absolutely wrong. Some people are very strict about using [t] instead of every fan-out, but I'm not one of them.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Fri, 18 Feb 2011 17:48:21 -0800 (PST) Jonathan Wilkes jancsika@yahoo.com wrote:
I guess I'm limiting it to unwanted ambiguities that _cannot_ be resolved by looking at the patch.
Maybe we could look at it in another way, and ask what information is hidden in a patch? Most we have mentioned so far:
- Values of IEM GUIs
- Creation order of cables
- Differing implementations of objects
- Creation order of objects
In that scheme, obscured things like inlets behind wires would count. Using real fancy graphics in a modern interface maybe some use of transparency can be made. I always liked the VST hosts where you could "shake" cables.
This made me think of a help to revealing (2). If an interface were to have hover-over tooltips, as has been discussed at times for outlets/inlets, then a cable could reveal its creation order on hover.
It wouldn't obviate triggers, but would make a nice debugging feature.
a.
On Fri, 18 Feb 2011, Hans-Christoph Steiner wrote:
On Feb 16, 2011, at 8:27 PM, Jonathan Wilkes wrote:
1 Don't have wires overlapping object boxes, object xlets, or object text* 2 Avoid horizontal wires
- good layout to represent the flow of the data
- encapsulation into rational chunks
- and more...
Hi. The topic is : what are sources of _ambiguïty_ in patching ? (how can we avoid ambiguïty in patching ?)
Thank you.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Thu, 17 Feb 2011, Andy Farnell wrote:
Yikes, I tried running that through De Morgans What is it you _do_ see there? Or does the law of the excluded middle prevent us from straying there? :)
Well, I'm just saying that the diagramme is the programme. Any inferences about portability and functional equivalence are irrelevant. If I have a visual dataflow language that only runs on MacOS 8.x with its own file format that isn't readable by anything else, the diagramme was the programme as well, there just isn't (wasn't) anyone to utter that sentence (back then).
portability and functional equivalence aren't any more important to visual dataflow languages than they are to any programming language. That means that they are important, but not correlated (affinely...).
Please, a list I'd like to see out of curiosity when you have a mo. I thought about that long and hard, mainly it was things like ambiguous connections where filaments cross over another object inlet, or horror of horrors, identical objects copied on top of each other and wired in place...I've been caught out that way before.
Fan-out is another kind of ambiguous connection. Each line may be unambiguous, but their combination order is not visible.
With Pd-extended's opaque boxes, you could be making mistakes involving NON-identical boxes on top of each other. But frankly, I don't recall this happening. (I was also the first one to advocate opaque boxes and show a prototype.)
IEMGUIs have lots of hidden settings : receive-symbol, send-symbol, init, lin-log.
All subpatches has to be opened in order to see a complete file on-screen, and each subpatch needs to be matchable to the box it appears as. Subpatches need titles that sufficiently appear in window titlebars. Note that only the $1 of a [pd] box appears in the titlebar. If you make a screenshot, don't overlap the windows.
Screenshots don't show complete patches if they have sliders, unless you use GridFlow's shoot.pd, which automatically moves the scrollbar and stitch the screenshots, but it doesn't do subpatches (and never shoots the whole screen). You can avoid this by using the Print function of Pd, which generates a PostScript file that has the wrong font and a somewhat different look, but that still doesn't do the subpatches automatically.
If you need to use [pix_video] to open the 2nd camera on OSX, and don't know any undocumented features, you need to create two [pix_video] objects, and use only the 2nd. Creation order matters here, so, if you cut the 1st one and undo, it becomes the 2nd. (I had to do this recently, because I didn't RTFS.)
[loadbang] creation order is like [pix_video] creation order, but a lot more common. There's also [gemhead] creation order (when forgetting to use priority numbers), etc. It doesn't get as weird as [receive] creation order, though.
I'll be honest it took a _lot_ of care. Out of well over 1000 diagrams one or two ambiguities have raised peoples annoyance enough to email me a "complaint". That's quite a good record I think, but I spent many hours re-arranging objects and coords to get clear and unambiguous patches.
Imagine if there were some kind of patchcord police that would automatically connect a [noise~] directly to a [dac~] whenever it sees an ambiguous patchcord. :}
What some recognise as my style now was heavily influenced by the writing and the need to have patches unambiguously read by eyes other than my own.
That's not a bad thing. How much time will you save on hunting down mistakes due to things that wouldn't happen to you anymore ?
Exactly as you say so succinctly, these are potential sounds, without the necessary performance parameters, ergo the relation between a parameter set and realised sounds. This is what I call deferred form, or for Rocchesso & Polotti, an unrealised sounding object. Indeed, I define that as one of the essential arts of procedural audio, the understanding of potentiality.
Did you think of yourself as a deferred form, an «unrealised» sounding objects with a hell of a lot of performance parameters ?
(life is a long song.)
Teaching requires clear, undistorted communication. If that communication fails, because the machine or the interpreter does not convey your intentions to the student, then the lesson fails. You could still keep part of your slogan, perhaps modify it to "The diagram is a program". Just maybe not the same program as mine.
Perhaps "All pd diagrams are programs, but some are more programs than others" ?
But that is true of programs written in any language... you can invent a similar language with different semantics, or install different versions of the same libraries, or different libraries with nameclashes, that will mean different things.
Do you know about those textfiles that can be run as either shell-scripts and tcl-scripts and use the differences between the two languages in order to be valid in both languages ? I don't remember what's the name for that. It's just one more reminder that the meaning of words is a matter of context, and that context can be an interpreter, or the expectations of someone who reads a text.
A patch is a kind of text.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 16 Feb 2011 20:39:33 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
With Pd-extended's opaque boxes, you could be making mistakes involving NON-identical boxes on top of each other. But frankly, I don't recall this happening. (I was also the first one to advocate opaque boxes and show a prototype.)
Imagine this disaster: You highlight an area of a dense, complex patch. By accident, while attempting to duplicate, you hit CTRLC then CTRLV, thus copying the entire area onto itself in place. The objects beneath continue to work of course, blindly spitting out data to things like arrays and sends. Meanwhile, you start to make new connections to what looks like a normal patch, but are in fact doppelgänger objects in the top copy.... hilarity ensues.
IEMGUIs have lots of hidden settings : receive-symbol, send-symbol, init, lin-log.
Yep. Fortunately these can be figured out in most cases.
All subpatches has to be opened in order to see a complete file on-screen,
Great in education, with good structure complex patches can be discussed in bite sized modular chunks. Hoorah! for sub-patches.
[loadbang] creation order
Good one. I forgot about this one.
--- On Thu, 2/17/11, Andy Farnell padawan12@obiwannabe.co.uk wrote:
From: Andy Farnell padawan12@obiwannabe.co.uk Subject: Re: [PD] FLOSS book Lists chapter To: "Mathieu Bouchard" matju@artengine.ca Cc: pd-list@iem.at Date: Thursday, February 17, 2011, 9:28 PM On Wed, 16 Feb 2011 20:39:33 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
With Pd-extended's opaque boxes, you could be making
mistakes involving
NON-identical boxes on top of each other. But frankly,
I don't recall this
happening. (I was also the first one to advocate
opaque boxes and show a
prototype.)
Imagine this disaster: You highlight an area of a dense, complex patch. By accident, while attempting to duplicate, you hit CTRLC then CTRLV, thus copying the entire area onto itself in place. The objects beneath continue to work of course, blindly spitting out data to things like arrays and sends. Meanwhile, you start to make new connections to what looks like a normal patch, but are in fact doppelgänger objects in the top copy.... hilarity ensues.
It's a lot more difficult to do this with pd-l2ork, because when you hit ctrl-v the objects are hanging from the mouse waiting to be placed by single-clicking on the canvas. In messing around, I've found the only way you can do this is to click ctrl-v multiple times, but you'll still end up with copies of the object-chain in a separate location from the original, hanging from your mouse as a clue that you're doing something really weird, and should click "Undo". (Actually, an undo history would come in really handy in this situation.)
One other failsafe would be to make "Tidy Up" fan out objects that are directly on top of each other.
IEMGUIs have lots of hidden settings :
receive-symbol, send-symbol, init,
lin-log.
Yep. Fortunately these can be figured out in most cases.
All subpatches has to be opened in order to see a
complete file on-screen,
Great in education, with good structure complex patches can be discussed in bite sized modular chunks. Hoorah! for sub-patches.
[loadbang] creation order
Same with [r] and many other objects that allow nonlocal connections.
Good one. I forgot about this one.
-- Andy Farnell padawan12@obiwannabe.co.uk
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
On Wed, Feb 16, 2011 at 09:36:52PM +0000, Andy Farnell wrote:
On Wed, 16 Feb 2011 15:44:02 -0500 (EST)
Is RjDj using ZenGarden, or LibPd, or both ?
Actually neither right now, tis Miller Vanilla with a little extra goodness by Amaury Hazan and Paul Brossier to make it work on those nasty iThings. Though what we call RjDj as a product rather than software base is now in its adolescence and may assume new forms with ZenGarden and/or LibPd and/or other frameworks AFAIK. You need to ask Martin Roth who is now in the captains seat for technology there.
IIRC the latest version of the RjDj app is not yet using libpd, but for the "Inception" movie tie-in app, which uses Pd/RjDj inside as well, the team has already made the switch to libpd, which is planned for future RjDj apps as well.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Thu, 17 Feb 2011, Frank Barknecht wrote:
IIRC the latest version of the RjDj app is not yet using libpd, but for the "Inception" movie tie-in app, which uses Pd/RjDj inside as well, the team has already made the switch to libpd, which is planned for future RjDj apps as well.
But what was RjDj using before using libpd ?
When Andy says "Vanilla with a little extra goodness", is it not LibPd...? Or is that something else ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Feb 17, 2011, at 10:04 AM, Mathieu Bouchard wrote:
On Thu, 17 Feb 2011, Frank Barknecht wrote:
IIRC the latest version of the RjDj app is not yet using libpd, but
for the "Inception" movie tie-in app, which uses Pd/RjDj inside as
well, the team has already made the switch to libpd, which is
planned for future RjDj apps as well.But what was RjDj using before using libpd ?
When Andy says "Vanilla with a little extra goodness", is it not
LibPd...? Or is that something else ?
Its closer to Vanilla minus a couple things, plus a couple tweaks, and
a chunk of other objects. rjdj is really a separate distro, its not
vanilla.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
-
Andy Farnell -
Frank Barknecht -
Hans-Christoph Steiner -
Jonathan Wilkes -
Mathieu Bouchard -
Pedro Lopes