On Sat, Oct 17, 2009 at 11:29:44PM +0100, alex wrote:
> 2009/10/16 Chris McCormick <chris_at_mccormick.cx>:
> > 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
>
> Interesting. Do you end up using [trigger] a lot in max too?
I'm not sure, I have never used max before.
> > 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?
I don't, but I think it would be possible to come up with some, especially in
the realm of low level DSP. Oh here's a similar example: I have seen an image
of a Plogue Bidule patch of the freeverb plugin which was easier for me to
understand than reading the C sourcecode of the same plugin.
One thing is for sure; the Java code would take up a lot more physical space to
make the same sound as a Pd patch. I guess that's because a Pd patch is geared
towards making sounds as quickly as possible, whilst Java is useful for a lot
more than that. The problem is, that is true of any language which you can do
more for less, so I don't think it proves me point about the graph being easier
to visually grok.
> But again, sorry to be boring but pd is textual.
Agree, Pd is most definately textual. I take your point that you have to read
what is in the boxes to understand what's going on, and what is in the boxes is
code.
What I am trying to work out is whether Pd's graph based layout gives us
something that isn't textual, and if so, why. All I have at the moment are
"programming feelings" that it's different, but I would like to establish
exactly how it's different.
> 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?
To me the difference is that the more declarative the language, the more you
surrender control over things like efficiency to the person who wrote the
compiler/interpereter. This is a grey scale and can be true at all levels.
When compiling C with gcc you are assuming that the people who worked on the
compiler were good enough that the resulting machine code will be as, or more
efficient than if you wrote assembler instead yourself. When you make a Pd
patch you are surrendering control to Miller Puckette, assuming that the
routines he wrote for passing data around between opcodes, scheduling execution
of opcodes, and often that the code of the opcodes themselves is efficient. In
an imperative language maybe you have more control over certain things like
flow control and scheduling, but at the expense of having to do everything
yourself. In a declarative language you can do things quickly that would
require a ridiculous amount of code in an imperative language. These are
generalisations of course.
> 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.
Yep, agree completely. I think you are in a unique position to see how you can
do graph-language like things with a completely text based language. Infact,
what you are doing with Haskell may be in some instances functionally exactly
the same as what people do in Pd. It's just the tool that's used to do it which
is different.
As to whether a graph based language is "more visual", I think you might be
right in saying it isn't. It still comes down to the definition of "visual".
> > 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?
Hm, no, you're right, that's fantasy.
At most I could say that you get some kind of an architectural
impression/overview more quickly than reading all of the code of a purely
textual language. Sometimes you can recognise certain patching idioms by the
arrangement of boxes on the screen but that relies on a) knowing the author's
patching style already and b) that style being 'clean' and c) reading what's in
some of the boxes anyway.
Actually this reminds me of something. You can recognise words by first and
last letter and length alone: <
http://www.languagehat.com/archives/000840.php>
I wonder if patching becomes the same. Maybe you can recognise programming
idioms in graph based languages by their graph shape and a couple of key
opcodes, without having the read what is inside every box?
Can you look at Dave's chilli-eating recursive totempoles and know from the
visual structure what kind of thing he is coding without reading what is in the
boxes themselves? Do certain elements of the totempole begin to look like a
certain sound-shape?
> > 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?
I am sure there are. I can't find it now, but I remember reading about a sound
making language which operated on the sample level and was fractal in nature.
That is, you programmed sequences of samples manually and then you did
recursive operations on those sequences to build more complex sequences. This
was right at the sample level though, so it got very noisey and weird. But I
think that type of thing would be very hard and not very useful to represent as
a graph.
For me, I mentally reduce pretty much everything to pictures anyway, so in Pd
because the flow control and architecture of the programs is represented as a
graph which is a picture, maybe that's why it seems easier to do certain types
of things.
At the end of the day though, Pd's many limitations get in the way of doing a
lot of stuff and so I always go back to good old C and Python (and other
friends!) when I'm doing tasks other than making music.
I would love to get my hands on a Free Software general purpose visual dataflow
programming language to see if it is actually useful to do every-day
programming tasks in.
Chris.
-------------------
http://mccormick.cx
Received on Sun Oct 18 2009 - 10:11:39 BST