[PD] FLOSS book Lists chapter

Mathieu Bouchard matju at artengine.ca
Thu Feb 17 02:39:33 CET 2011


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


More information about the Pd-list mailing list