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