I'm not sure but Im guessing that most people here came to livecoding
and programming audio via erm , well programming?
I came to use pd/max/csound blah blah after many years spent patching
real cables and messing with desks, fx pedals,microphones and midi cables.
I think the analogy to physical patching in systems like pd/max really
helps for people who come from this more physical setup?
maybe the same reason I actually like 'desktops' in OSs too..
Tom Betts
----------------------
www.nullpointer.co.uk
www.odessadesign.co.uk
----------------------
Correa Diego wrote:
> 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 <jeff_at_rosejn.net <mailto: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 <dave_at_pawfal.org <mailto: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/
>
> 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
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.14.3/2415 - Release Date: 10/05/09 06:19:00
>
Received on Mon Oct 05 2009 - 16:08:28 BST