2009/10/16 Chris McCormick <chris_at_mccormick.cx>:
> 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.
Interesting. Do you end up using [trigger] a lot in max too?
> 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.
Aha, thanks for this clarification.
> 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!
Very interesting point, important I think. Do you have an example of
PD code that is instantly understandable at a glance, that is
difficult to understand in (say) idiomatic java code?
But again, sorry to be boring but pd is textual. Maybe your criticism
is valid, but of imperative programming, as I think you're hinting at
the end there. I have a hard time conceptually separating declarative
and imperative programming -- what is the actual difference between
saying what you want done and how you want to do something? But
apparently dataflow programming (e.g. PD) and pure functional
programming (e.g. haskell) are both declarative, and c, java,
supercollider et al are imperative. Also it turns out that functional
reactive programming is a kind of dataflow programming, so what I've
been trying to do with my haskell stuff is dataflow as well.
> 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.
You seem to be suggesting that you can understand a patch without
reading what's in the boxes. How?
> 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.
Yes, box-and line graphs are an excellent way of mentally modelling
what is going on in an abstract audio processing graph. Are there
approaches to audio synthesis that aren't so natural to graphs though?
alex
--
http://yaxu.org/
Received on Sat Oct 17 2009 - 22:29:56 BST