On Thu, Oct 15, 2009 at 05:50:00PM +0100, alex wrote:
> While I'm hear, it's transfer at goldsmiths tomorrow!
> http://slab.org/transfer/
>
> 2009/10/15 evan.raskob [lists] <lists_at_lowfrequency.org>:
> > And I also have to disagree
> > about the position of boxes on the screen - it's a fundamental part of
> > MaxMSP that things happen from left-to-right (this is not the case in Pd)
> > and so you *must* read patches from left-to-right otherwise you will get
> > drastically different results, as anyone who has done any real patching in
> > Max knows.
>
> In Pd, execution order is the order than you connect the wires in.
That's true, but relying on it is strongly discouraged. You're supposed to
treat execution order as "undefined" if it isn't explicit, i.e. if there is
"connection fanning" and you can't immediately see at a glance what the
execution order will be. The way to make execution order explicit and visually
obvious is to use the [trigger] object, which always fires right to left. I
think this is due to a goal of Pd being that patches can be logically followed
even if you only have a print-out or napkin sketch of a patch, outside of the
execution environment.
> 8/ Some myth about max being more 'visual' means people drop their guard
I think this issue is complicated because there are two different ways in which
data flows through patches. Audio data flows in a way that looks concurrent. To
a piece of audio data, it looks like every ugen on the patch is running
simultaneously. A ugen won't get run until all of its inlets are satisfied with
data. Control data and messages on the other hand, have a definite execution
order. Objects will execute when their 'hot' inlets receive data - you don't
have to send data to every inlet to make them execute.
So in terms of audio data, I think it's immediately obvious what's going on
when you look at the graph. Unlike textual programming languages, you can see
at a glance what is happening. With textual programming languages you need to
trace what is happening at each point of execution in your program before you
can understand how the data flows through it. Note that I have not done much
programming in languages like Haskell so this could be lies!
When it comes to the message passing side, once again you can see pretty
quickly what's going on, but you much more have to read what's in the boxes
(like regular programming) to understand how the patch is executed. This is
because message passing networks are not fake-concurrent, whilst audio networks
are fake-concurrent.
Graphs are a good way of mentally modelling what is going on. Languages which
use graphs explicitly don't require you to hold the graph in your head since
it's there on the screen. Maybe? I dunno.
Chris.
-------------------
http://mccormick.cx
Received on Fri Oct 16 2009 - 21:26:19 BST