[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