Re: [PD] FLOSS book Lists chapter
On Mon, 21 Feb 2011, Hans-Christoph Steiner wrote: I agree avoiding horizontal connections is good. the 5% of the time when segmented patch cord are useful is when you need to take a patch cord from the bottom to the top of a patch to make a loop. You mean that you only need to make loops 5 % of the time ? geez. What does 5 % of the time mean ? Is it 5 % of the patches or 5 % of the cords ? But it's really not only about loops. ___ | 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
Re: [PD] FLOSS book Lists chapter
On Feb 19, 2011, at 9:50 PM, Jonathan Wilkes wrote: --- On Sun, 2/20/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Sunday, February 20, 2011, 1:40 AM On Sat, 19 Feb 2011, Jonathan Wilkes wrote: I'll continue to argue if hc gives me some Pd examples that back up his 95% bad claim. But unless I'm missing a turn on segmented patch cords checkbutton buried in a menu somewhere, I believe this is the end of the argument. The claim has been used for a long time, to justify why pd doesn't have this feature. Even though Pd doesn't have it, MAX has it, and this is what people here refer to when they talk about segmented patch cords (most of the time). http://cycling74.com/docs/max5/vignettes/core/max_alphabetical.html I started at the top, checked the help for all the objects under symbols and A. Thirty-five help docs with 27 segmented patch cords, and _none_ of them are ambiguous. So what exactly are people referring to, other than some anecdotal evidence about some students somewhere who made some patches with some segmented patch cords that they thought looked bad? http://cycling74.com/docs/max5/refpages/max-ref/logand.html The patch on the right side would be clearer if the patch cords were straight lines, rather than having little corners near the inlet/ outlets. To my eye, the horizontal cords merge with the horizontal lines of the object boxes. http://cycling74.com/docs/max5/refpages/max-ref/accum.html The feedback on the right side is the only time I think its good. The left side, the cords start to less readable since they are only horizontal. The direction of the cords to [2( and [4( does not point towards its destintation, but instead towards off screen. http://cycling74.com/docs/max5/refpages/max-ref/atan.html Again, the cords don't point towards their destintations. That means you're eye has to trace the line to see where it goes rather than skim it. .hc If you are not part of the solution, you are part of the problem. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
I agree avoiding horizontal connections is good. the 5% of the time when segmented patch cord are useful is when you need to take a patch cord from the bottom to the top of a patch to make a loop. .hc On Feb 19, 2011, at 4:12 PM, Jonathan Wilkes wrote: How can you say that segmented patch cords are bad 95% of the time when they are not even available in Pd 100% of the time? Just to take Miller's Techniques as an example, if there were segmented patch cords then all of his horizontal connections could be made unambiguous by having about 5px of vertical cord segment directly above the inlet. Also, I've never seen you complain about any of the ASCII art on the this list, which often (surely more than 5% of the time) uses - and | at 90-degree angles and + to make segmented patch cords. -Jonathan From: Hans-Christoph Steiner h...@at.or.at; To: Marco Donnarumma de...@thesaddj.com; Cc: pd-list@iem.at; Subject: Re: [PD] FLOSS book Lists chapter Sent: Sat, Feb 19, 2011 6:48:10 PM On Feb 19, 2011, at 12:46 PM, Marco Donnarumma wrote: 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. +1 I don't think the connection order should be exposed. I really think that the GUI should not encourage bad programming practice. Its also this same reason why I think that 95% of the time, segmented patch cords are bad. But yes, tooltips showing what messages an inlet expects would be great to have. Check out the l2ork distro for the new version of J.Sarlo's magic glass cord inspector. .hc http://at.or.at/hans/ I hate it when they say, He gave his life for his country. Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
No In the Air Tonight was a song about a really smelly fart Phil Collins did. On Sat, 19 Feb 2011 23:56:02 -0800 (PST) Jonathan Wilkes jancs...@yahoo.com wrote: --- On Sun, 2/20/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Sunday, February 20, 2011, 5:01 AM On Sat, 19 Feb 2011, Jonathan Wilkes wrote: So what exactly are people referring to, other than some anecdotal evidence about some students somewhere who made some patches with some segmented patch cords that they thought looked bad? I mean that they might be referring to anecdotal evidence involving MAX. Yeah, I heard that this one guy had so many segmented patch cords in Max that he got tangled up in them, and he drowned, and Phil Collins saw it happen and wrote the song In the Air Tonight about the incident. -Jonathan ___ | 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 -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
maybe it's time to change the subject of this thread? M So what exactly are people referring to, other than some anecdotal evidence about some students somewhere who made some patches with some segmented patch cords that they thought looked bad? I mean that they might be referring to anecdotal evidence involving MAX. Yeah, I heard that this one guy had so many segmented patch cords in Max that he got tangled up in them, and he drowned, and Phil Collins saw it happen and wrote the song In the Air Tonight about the incident. -Jonathan ___ | Mathieu Bouchard t?l: +1.514.383.3801 Villeray, Montr?al, QC -- Marco Donnarumma Independent New Media and Sonic Arts Professional, Performer, Instructor ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK ~ Portfolio: http://marcodonnarumma.com Lab: http://www.thesaddj.com | http://cntrl.sourceforge.net | http://www.flxer.net Event: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
--- On Sun, 2/20/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: Hans-Christoph Steiner h...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
On Fri, 18 Feb 2011 17:48:21 -0800 (PST) Jonathan Wilkes jancs...@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: 1) Values of IEM GUIs 2) Creation order of cables 3) Differing implementations of objects 4) 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. -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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. +1 -- Marco Donnarumma Independent New Media and Sonic Arts Professional, Performer, Instructor ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK ~ Portfolio: http://marcodonnarumma.com Lab: http://www.thesaddj.com | http://cntrl.sourceforge.net | http://www.flxer.net Event: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
On Feb 19, 2011, at 12:46 PM, Marco Donnarumma wrote: 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. +1 I don't think the connection order should be exposed. I really think that the GUI should not encourage bad programming practice. Its also this same reason why I think that 95% of the time, segmented patch cords are bad. But yes, tooltips showing what messages an inlet expects would be great to have. Check out the l2ork distro for the new version of J.Sarlo's magic glass cord inspector. .hc http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
How can you say that segmented patch cords are bad 95% of the time when they are not even available in Pd 100% of the time? Just to take Miller#39;s Techniques as an example, if there were segmented patch cords then all of his horizontal connections could be made unambiguous by having about 5px of vertical cord segment directly above the inlet. Also, I#39;ve never seen you complain about any of the ASCII art on the this list, which often (surely more than 5% of the time) uses - and | at 90-degree angles and + to make segmented patch cords. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
If you never depend on connection order (which you sholdn#39;t because, as we#39;ve discussed, it is visually ambiguous), then how exactly would that help you debug? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
Regarding ambiguity, I#39;d say a good rule of thumb is that one should be able to draw the patch on a sheet of paper without introducing any ambiguity. So things like inlet tool tips and cord shaking don#39;t resolve ambiguity in the visual representation of the patch, though they may be useful in other ways. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
On Sat, 19 Feb 2011, Jonathan Wilkes wrote: How can you say that segmented patch cords are bad 95% of the time when they are not even available in Pd 100% of the time? Just to take Miller's Techniques as an example, if there were segmented patch cords then all of his horizontal connections could be made unambiguous by having about 5px of vertical cord segment directly above the inlet. If you continue arguing this, you could be wasting as much time as I did ! ___ | 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
Re: [PD] FLOSS book Lists chapter
--- On Sat, 2/19/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Saturday, February 19, 2011, 10:42 PM On Sat, 19 Feb 2011, Jonathan Wilkes wrote: How can you say that segmented patch cords are bad 95% of the time when they are not even available in Pd 100% of the time? Just to take Miller's Techniques as an example, if there were segmented patch cords then all of his horizontal connections could be made unambiguous by having about 5px of vertical cord segment directly above the inlet. If you continue arguing this, you could be wasting as much time as I did ! I'll continue to argue if hc gives me some Pd examples that back up his 95% bad claim. But unless I'm missing a turn on segmented patch cords checkbutton buried in a menu somewhere, I believe this is the end of the argument. -Jonathan ___ | 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
Re: [PD] FLOSS book Lists chapter
On Sat, 19 Feb 2011, Jonathan Wilkes wrote: I'll continue to argue if hc gives me some Pd examples that back up his 95% bad claim. But unless I'm missing a turn on segmented patch cords checkbutton buried in a menu somewhere, I believe this is the end of the argument. The claim has been used for a long time, to justify why pd doesn't have this feature. Even though Pd doesn't have it, MAX has it, and this is what people here refer to when they talk about segmented patch cords (most of the time). ___ | 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
Re: [PD] FLOSS book Lists chapter
--- On Sun, 2/20/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Sunday, February 20, 2011, 1:40 AM On Sat, 19 Feb 2011, Jonathan Wilkes wrote: I'll continue to argue if hc gives me some Pd examples that back up his 95% bad claim. But unless I'm missing a turn on segmented patch cords checkbutton buried in a menu somewhere, I believe this is the end of the argument. The claim has been used for a long time, to justify why pd doesn't have this feature. Even though Pd doesn't have it, MAX has it, and this is what people here refer to when they talk about segmented patch cords (most of the time). http://cycling74.com/docs/max5/vignettes/core/max_alphabetical.html I started at the top, checked the help for all the objects under symbols and A. Thirty-five help docs with 27 segmented patch cords, and _none_ of them are ambiguous. So what exactly are people referring to, other than some anecdotal evidence about some students somewhere who made some patches with some segmented patch cords that they thought looked bad? -Jonathan ___ | 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
Re: [PD] FLOSS book Lists chapter
On Sat, 19 Feb 2011, Jonathan Wilkes wrote: So what exactly are people referring to, other than some anecdotal evidence about some students somewhere who made some patches with some segmented patch cords that they thought looked bad? I mean that they might be referring to anecdotal evidence involving MAX. ___ | 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
Re: [PD] FLOSS book Lists chapter
--- On Sun, 2/20/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Sunday, February 20, 2011, 5:01 AM On Sat, 19 Feb 2011, Jonathan Wilkes wrote: So what exactly are people referring to, other than some anecdotal evidence about some students somewhere who made some patches with some segmented patch cords that they thought looked bad? I mean that they might be referring to anecdotal evidence involving MAX. Yeah, I heard that this one guy had so many segmented patch cords in Max that he got tangled up in them, and he drowned, and Phil Collins saw it happen and wrote the song In the Air Tonight about the incident. -Jonathan ___ | 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
Re: [PD] FLOSS book Lists chapter
I noticed this too.
Miller is quite fond of using it in Theory and Techniques.
I do from time to time, but only if the connection
is a leftmost or rightmost control/message connection.
For certain kinds of patch, where you mostly have
audio DSP runnimg down the page, and occasional
parameterisation by number or recieve boxes to the
sides, having them hoizontal makes for a kind of
nice clarity, audio vertical, messages horizontal.
But break the rule rather than do anything ambiguous.
On Thu, 17 Feb 2011 15:13:05 -0800 (PST)
Jonathan Wilkes jancs...@yahoo.com wrote:
--- On Thu, 2/17/11, Mathieu Bouchard ma...@artengine.ca wrote:
From: Mathieu Bouchard ma...@artengine.ca
Subject: Re: [PD] FLOSS book Lists chapter
To: Jonathan Wilkes jancs...@yahoo.com
Cc: padawa...@obiwannabe.co.uk, pd-list@iem.at
Date: Thursday, February 17, 2011, 9:25 PM
On Thu, 17 Feb 2011, Jonathan Wilkes
wrote:
if { $xlets_involved 2 } { menu_doc_open
attachment_dir horiz-connections.pd }
Error: Success
Now what's the problem with horizontal wires ?
I mean those that aren't overlapping any inlets or outlets,
not the ones in your patch.
Here's a revised version where the wires aren't overlapping.
How do you know they aren't overlapping?
1) Use pd-ext and notice the difference between the 1px gray box and the
1px black connections.
2) Actually move the object to _reveal_ that the connection don't overlap.
3) Always assume that the patch creator followed the rule of don't
overlap xlets.
1 is implementation specific and ridiculously subtle for an
environment where the diagram is the code, 2 is wasting people's time
by making them fuss around in the patch in order to be sure they
understand what it does, and 3 is easy to screw up:
__[inlet]_
[f][f]
(On a narrow object like [f] it's very easy to make a connection to the
wrong inlet. Well, not as easy on pd-l2ork...)
So I guess qualify it to no horizontal connections unless there's only 1
inlet and 1 outlet involved.
-Jonathan
(We already agreed against
overlapping wires)
___
| Mathieu Bouchard tél: +1.514.383.3801
Villeray, Montréal, QC
--
Andy Farnell padawa...@obiwannabe.co.uk
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
--- On Fri, 2/18/11, Andy Farnell padawa...@obiwannabe.co.uk wrote:
From: Andy Farnell padawa...@obiwannabe.co.uk
Subject: Re: [PD] FLOSS book Lists chapter
To: Jonathan Wilkes jancs...@yahoo.com
Cc: Mathieu Bouchard ma...@artengine.ca, pd-list@iem.at
Date: Friday, February 18, 2011, 7:46 PM
I noticed this too.
Miller is quite fond of using it in Theory and
Techniques.
1) http://crca.ucsd.edu/~msp/techniques/latest/book-html/node36.html
[phasor~] crossing the right inlet of [-~] is completely unecessary,
solved merely by moving [-~], [*~], and [cos~] down by 10 px or so.
2) http://crca.ucsd.edu/~msp/techniques/latest/book-html/node53.html
looks better as attached with the two messages controling [line~]
next to each other.
3) http://crca.ucsd.edu/~msp/techniques/latest/book-html/node119.html
Still unnecessary, but these benefit from signal connections being
thicker so that there is a 1px corner where the wire meets the
corresponding inlet (basically just a subtle, automatic segmented
patch cord).
There are lots of others but I don't see how the modest aesthetic bonus
of a completely straight line segment outweighs potential ambiguity
created by them.
I do from time to time, but only if the connection
is a leftmost or rightmost control/message connection.
For certain kinds of patch, where you mostly have
audio DSP runnimg down the page, and occasional
parameterisation by number or recieve boxes to the
sides, having them hoizontal makes for a kind of
nice clarity, audio vertical, messages horizontal.
It might look nice but if the object being connected to
has more than one inlet there is an ambiguity in the
patch. This may be fine for a picture of a patch where
the correct connection is obvious, but for an actual
patching habit it's terrible because a subtle, persistent
bug can easily cause you to start searching through your
patch for all such horizontal cord ambiguities and moving
around the relevant objects.
It's exactly the same problem as seeing closely spaced
objects:
[1(
[slay-fire-breathing-dragon]
Why risk it?
The only rational I can think of is: looks clean. Which, for a piece
of software that relies on black mono-spaced text with black
lines running over it, strikes [through] me as odd*.
-Jonathan
But break the rule rather than do anything ambiguous.
My rule avoids all the ambiguity addressed above (well, except for
black lines running through black text).
-Jonathan
On Thu, 17 Feb 2011 15:13:05 -0800 (PST)
Jonathan Wilkes jancs...@yahoo.com
wrote:
--- On Thu, 2/17/11, Mathieu Bouchard ma...@artengine.ca
wrote:
From: Mathieu Bouchard ma...@artengine.ca
Subject: Re: [PD] FLOSS book Lists chapter
To: Jonathan Wilkes jancs...@yahoo.com
Cc: padawa...@obiwannabe.co.uk,
pd-list@iem.at
Date: Thursday, February 17, 2011, 9:25 PM
On Thu, 17 Feb 2011, Jonathan Wilkes
wrote:
if { $xlets_involved 2 } {
menu_doc_open
attachment_dir horiz-connections.pd }
Error: Success
Now what's the problem with horizontal wires ?
I mean those that aren't overlapping any inlets
or outlets,
not the ones in your patch.
Here's a revised version where the wires aren't
overlapping.
How do you know they aren't overlapping?
1) Use pd-ext and notice the difference between the
1px gray box and the
1px black connections.
2) Actually move the object to _reveal_ that the
connection don't overlap.
3) Always assume that the patch creator followed the
rule of don't
overlap xlets.
1 is implementation specific and ridiculously subtle
for an
environment where the diagram is the code, 2 is
wasting people's time
by making them fuss around in the patch in order to be
sure they
understand what it does, and 3 is easy to screw up:
__[inlet]_
[f] [f]
(On a narrow object like [f] it's very easy to make a
connection to the
wrong inlet. Well, not as easy on pd-l2ork...)
So I guess qualify it to no horizontal connections
unless there's only 1
inlet and 1 outlet involved.
-Jonathan
(We already agreed against
overlapping wires)
___
| Mathieu Bouchard tél: +1.514.383.3801
Villeray, Montréal, QC
--
Andy Farnell padawa...@obiwannabe.co.uk
example-2.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
On Feb 16, 2011, at 8:27 PM, Jonathan Wilkes wrote: --- On Thu, 2/17/11, Andy Farnell padawa...@obiwannabe.co.uk wrote: From: Andy Farnell padawa...@obiwannabe.co.uk Subject: Re: [PD] FLOSS book Lists chapter To: Mathieu Bouchard ma...@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 ma...@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... .hc [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
I created a new account on booki with my same account name: HansChristophSteiner. Seemed to work fine. .hc On Feb 17, 2011, at 6:10 AM, adam hyde wrote: hey i am working on this at the moment (see list if youa re still sub'ed...just mailed it about this). hope it is sorted out next week as for logonsyou need to create a new account on the new fm booki adam On Fri, 2011-02-11 at 19:30 +0100, Derek Holzer wrote: HC: I don't think the Booki pages are meant to be used yet. Proper URL would be: http://en.flossmanuals.net/bin/view/PureData/Lists To Adam and Aco: will the old stuff get synched/transferred to the new Booki pages at some point? Will the URL of the Pd FLOSS Manual change to the Booki one? Also, my login for the old pages doesn't work on the new Booki pages, nor am I notified of changes to the new Booki based chapters. Please clarify. Best, Derek On 2/11/11 5:25 PM, Hans-Christoph Steiner wrote: I just updated the Lists chapter in the FLOSS Manuals Pure Data book, I'd love to have some people review it: http://booki.flossmanuals.net/pure-data/edit/ .hc -- Adam Hyde Founder FLOSS Manuals Booki Project Manager Contact Information German mobile : + 49 177 4935122 Email : a...@flossmanuals.net irc : irc.freenode.net #flossmanuals Free manuals for free software http://www.flossmanuals.net/about Free Software for making Free Books http://www.booki.cc/ News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
--- On Sat, 2/19/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: Mathieu Bouchard ma...@artengine.ca, Andy Farnell padawa...@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 padawa...@obiwannabe.co.uk wrote: From: Andy Farnell padawa...@obiwannabe.co.uk Subject: Re: [PD] FLOSS book Lists chapter To: Mathieu Bouchard ma...@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 ma...@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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
Hi, On Wed, Feb 16, 2011 at 09:36:52PM +, 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 BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
if { $xlets_involved 2 } { menu_doc_open attachment_dir horiz-connections.pd }
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
horiz-connections.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
On Thu, 17 Feb 2011, Jonathan Wilkes wrote:
if { $xlets_involved 2 } { menu_doc_open attachment_dir horiz-connections.pd }
Error: Success
Now what's the problem with horizontal wires ?
I mean those that aren't overlapping any inlets or outlets, not the ones
in your patch. (We already agreed against overlapping wires)
___
| 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
Re: [PD] FLOSS book Lists chapter
On Wed, 16 Feb 2011 20:39:33 -0500 (EST) Mathieu Bouchard ma...@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. -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
--- On Thu, 2/17/11, Mathieu Bouchard ma...@artengine.ca wrote:
From: Mathieu Bouchard ma...@artengine.ca
Subject: Re: [PD] FLOSS book Lists chapter
To: Jonathan Wilkes jancs...@yahoo.com
Cc: padawa...@obiwannabe.co.uk, pd-list@iem.at
Date: Thursday, February 17, 2011, 9:25 PM
On Thu, 17 Feb 2011, Jonathan Wilkes
wrote:
if { $xlets_involved 2 } { menu_doc_open
attachment_dir horiz-connections.pd }
Error: Success
Now what's the problem with horizontal wires ?
I mean those that aren't overlapping any inlets or outlets,
not the ones in your patch.
Here's a revised version where the wires aren't overlapping.
How do you know they aren't overlapping?
1) Use pd-ext and notice the difference between the 1px gray box and the
1px black connections.
2) Actually move the object to _reveal_ that the connection don't overlap.
3) Always assume that the patch creator followed the rule of don't
overlap xlets.
1 is implementation specific and ridiculously subtle for an
environment where the diagram is the code, 2 is wasting people's time
by making them fuss around in the patch in order to be sure they
understand what it does, and 3 is easy to screw up:
__[inlet]_
[f][f]
(On a narrow object like [f] it's very easy to make a connection to the
wrong inlet. Well, not as easy on pd-l2ork...)
So I guess qualify it to no horizontal connections unless there's only 1
inlet and 1 outlet involved.
-Jonathan
(We already agreed against
overlapping wires)
___
| Mathieu Bouchard tél: +1.514.383.3801
Villeray, Montréal, QC
horiz-connections2.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
--- On Thu, 2/17/11, Andy Farnell padawa...@obiwannabe.co.uk wrote: From: Andy Farnell padawa...@obiwannabe.co.uk Subject: Re: [PD] FLOSS book Lists chapter To: Mathieu Bouchard ma...@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 ma...@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 padawa...@obiwannabe.co.uk ___ 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
Re: [PD] FLOSS book Lists chapter
On Tue, Feb 15, 2011 at 03:09:35PM -0800, Jonathan Wilkes wrote: --- On Tue, 2/15/11, Mathieu Bouchard ma...@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 BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
On Tue, 15 Feb 2011 13:19:35 -0500 (EST) Mathieu Bouchard ma...@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 -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
On Wed, 16 Feb 2011 15:44:02 -0500 (EST) Mathieu Bouchard ma...@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 -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
On Wed, 16 Feb 2011, Andy Farnell wrote: On Wed, 16 Feb 2011 15:44:02 -0500 (EST) Mathieu Bouchard ma...@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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
--- On Wed, 2/16/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: Hans-Christoph Steiner h...@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 ma...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
On Wed, 16 Feb 2011 16:55:24 -0500 (EST) Mathieu Bouchard ma...@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 -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
--- On Thu, 2/17/11, Andy Farnell padawa...@obiwannabe.co.uk wrote: From: Andy Farnell padawa...@obiwannabe.co.uk Subject: Re: [PD] FLOSS book Lists chapter To: Mathieu Bouchard ma...@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 ma...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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
Re: [PD] FLOSS book Lists chapter
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
--- On Tue, 2/15/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: Hans-Christoph Steiner h...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
On Tue, 15 Feb 2011, Jonathan Wilkes wrote: --- On Tue, 2/15/11, Mathieu Bouchard ma...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
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
Re: [PD] FLOSS book Lists chapter
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 ma...@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 -- Pedro Lopes (MSc) contact: pedro.lo...@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes / http://pedrolopesresearch.wordpress.com/ | http://twitter.com/plopesresearch ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
--- On Sun, 2/13/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: Hans-Christoph Steiner h...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] FLOSS book Lists chapter
I just updated the Lists chapter in the FLOSS Manuals Pure Data book, I'd love to have some people review it: http://booki.flossmanuals.net/pure-data/edit/ .hc Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
HC: I don't think the Booki pages are meant to be used yet. Proper URL would be: http://en.flossmanuals.net/bin/view/PureData/Lists To Adam and Aco: will the old stuff get synched/transferred to the new Booki pages at some point? Will the URL of the Pd FLOSS Manual change to the Booki one? Also, my login for the old pages doesn't work on the new Booki pages, nor am I notified of changes to the new Booki based chapters. Please clarify. Best, Derek On 2/11/11 5:25 PM, Hans-Christoph Steiner wrote: I just updated the Lists chapter in the FLOSS Manuals Pure Data book, I'd love to have some people review it: http://booki.flossmanuals.net/pure-data/edit/ .hc -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 204: What do you do? Now, what do you do best?' ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
A false dichotomy is made between abstractions and externals. Also there are many externals that don#39;t include abstractions but are nonetheless compatible with Pd vanilla. word or symbol creates a false dichotomy. Also: it isn#39;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*. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
