To my experience, it depends on where you come from how easy a system
seems. For many people who have never soldered, patched etc. pd/max
is far more difficult to understand conceptually than a text based
system. If you come from literature, the magic of code is maybe more
attractive than if you come from sound engineering or live
electronics.
Apart from this, my impression is that the heart of live coding (just
as eventually art and science) is to work against majoritarian
intuition to establish unconditioned thought. This may take any shape
whatsoever, and of course needs to depart from intuition. In other
words, ergonomics makes sense if you know everything about the body,
however it is a hindrance if you don't, because it does not yet exist.
So a question perhaps: Is the attempt to make the audience understand
as much as possible helpful for one's own understanding? I think yes,
but it might be something different than sound that is understood.
>Hi Group,
>
>I think there are some clues a step behind what we visually see. The
>visual model is just information we actually interpret, but at the
>same time is, as someone said already in this discussion,
>practically irrelevant to the functional structure of algorithms
>in PD/MAX type systems once they're made and executed.
>
>All that "mess" we see in a patch, which i would call "guts", is
>some kind of higher level order that the computer doesn't need to
>interpret but is useful for the experience of the developer. What we
>are understanding is that the visual system of a human being is far
>more complex and, maybe, impossible to model in a computer system as
>we know them. That complexity in perception could be used in the
>construction of a graphical programming language, independent from
>which that could be. At last, we could be talking about "auditory
>programming language" and the debate would be somehow equivalent in
>its approach.
>
>greets,
>
>Diego
>
>2009/10/5 Jeff Rose <<mailto:jeff_at_rosejn.net>jeff_at_rosejn.net>
>
>I see where you are coming from, and when I first used PD after
>being a programmer for years I found it to be just a clunky
>scripting language. For someone who is new to programming though, I
>think this is far from the case. (I don't claim to be an expert,
>but this is my current thinking after having taught a couple
>semesters of undgraduate programing and having tutored my brother in
>Max.)
>
>I think it has to do with your mental model while coding, more than
>some technical difference in the languages. To someone who has
>programming experience their is a large abstract model that comes
>into "view" while you are working on a project. You balance all
>sorts of things in your mind, from top level architectural analogies
>to concrete syntactic constructs at your current line of code. In
>an audio system you build up a picture of the signal and control
>flows in your mind, and then modify and manipulate these mental
>flows by writing functions.
>
>To a new programmer there is virtually a blank slate when first
>coding though, and without having a toolbox of typical components in
>mind or memories of past projects, I think it is very difficult for
>beginners to keep an accurate mental model in mind. Having a patch
>on screen, where you can constantly check things, look at signals
>flow, watch buttons and number boxes update, etc., it all helps
>very, very much to inform this nascent mental model. My brother
>would create max patches where debug lines were connected to almost
>everything possible because he liked to have a "live" feel for what
>was happening in the patch. Even with modern IDEs this is quite
>tedious to setup, let alone in emacs or vim (where I feel at home).
> It also allows for run-time experimentation in a way that even
>using a REPL doesn't duplicate. (Because you can easily watch the
>effects of your changes on the rest of the patch, rather than
>implicitly "watching" them in your mental model and then just
>checking a variable or two to verify your intuitions.)
>
>So yeah sure, they are Turing complete and you still type function
>names and arguments, but I think the real reason visual programming
>is nice for people with no programming experience is because it
>dramatically helps clarify and remind them of the working model of
>their program.
>
>Interestingly, I think that this same benefit in the beginning
>stages becomes the primary drawback at later stages. While in
>"real" programming languages you have good tools for creating
>abstractions so that you can think at higher and higher levels, I
>think in Max you are kind of stuck at a sort of medium level of
>abstraction no matter what. Big patches with many interconnected
>components are far messier than the equivalent program would be, and
>once you get to that point I think you already have to be operating
>on a decent mental model anyways. (Which is I think why many people
>who get proficient in Max want to move on to programming in
>javascript, C, Clojure :-)
>
>That's my 2 cents anyway.
>
>-Jeff
>
>
>alex wrote:
>
>2009/10/5 Dave Griffiths <<mailto:dave_at_pawfal.org>dave_at_pawfal.org>:
>
>The difference between text and graphical programming seems fairly
>arbitrary to me
>
>
>I make this point every time this discussion comes up but it seems
>no-one either agrees or disagrees with me. Maybe I'm not making any
>sense. I'll try again.
>
>Pd and max are not graphical programming languages. They are textual.
> They are no more visual than C. You make an object and it does
>nothing until you give it a name. Then you connect it to other
>objects also with names. You move the boxes around the screen and the
>meaning doesn't change (except with weird edge cases in Max, but
>that's a side issue).
>
>Maybe if I make an outrageous statement someone will disagree with me;
>when artists who say they find pd or max more intuitive than textual
>languages because they are more visual and therefore more in tune with
>their visual thinking are plain wrong. They don't understand how they
>think, and don't know what they're doing, just like everyone else.
>They are using a symbolic language to make art and shouldn't be afraid
>to admit it.
>
>There are language differences between PD and supercollider but
>spatial and non-spatial is not one of them. Both allow symbolic
>abstractions, loops and conditionals, and both require abstract
>thought to make or understand a patch.
>
><http://yaxu.org/textual-patching/>http://yaxu.org/textual-patching/
>
>I think what makes live coding is some system where a human composes a
>string of symbols from an alphabet, while a process interprets the
>string according to some Turing complete language rules, so that the
>interpreter follows changes to the code.
>
>You might have a language that isn't Turing complete, but still allows
>interesting abstractions, and call that live coding. I'm not sure if
>I'd agree or not, that would be an interesting route to follow but for
>now I think the turing-completeness is important.
>
>alex
>
>
>
>
>--
><http://labormedia.cl/algoritmia>http://labormedia.cl/algoritmia
--
.
Received on Mon Oct 05 2009 - 21:14:53 BST