On Thu, Oct 15, 2009 at 10:02 AM, evan.raskob [lists]
<lists_at_lowfrequency.org> wrote:
> Eh, not true! There was a big movement a few years ago to use sends and
> receives to create "namespaces" in MaxMSP. 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.
The X position of objects in Max is important only for deciding order
of message passing. However, how far or close the boxes are placed
from each other is irrelevant. Also, the position/order of boxes on
the Y axis is completely irrelevant (to the parser, anyways). Also,
the position of boxes on X can be arbitrary but made explicit via
other means (as Chris has already pointed out). I do not think that
this aspect makes a strong point in favour of importance of the
position of boxes on the screen. In Max, Pd, other visual as well as
textual languages, the positioning of elements on the screen is a way
of making them easier to understand, analyze and visualize the data
flow.
Just like C, source code "written" in Max can be obfuscated.
> The underlying metaphors of text and patching are also very
> different. Pd and Max were originally designed to look like audio control
> systems of the time - boxes plugged into other boxes in series. Then came
> the DSP portion of them (they started out as pure control data; MIDI) and
> the metaphor evolved a bit to include analog synthesizers and their arrays
> of function generators and patch cables.
Yes but I also recall reading somewhere that Miller P. intended the
early Max only as a control interface to the FTS system and he was
surprised to see that some users/programmers used it to actually
program musical logic. That led to further development to facilitate
such use. Today Max and Pd are full-featured programming languages
(hmm, let's go easy on the "full-featured" part, ok?).
> Anyway, the funny thing is that now that I've come to the end of this long
> rant, I just had an offline conversation with Dave about this, and I think
> I've been intellectually nudged closer to the central view that the real
> issue is about accessibility, there is less difference between text and
> image (even though I reserve the view that there is a neurological basis for
> treating them differently) and the "accident" of using text to describe
> complex instructions (computer programs) to machines due to typewriters
> being so ubiquitous. I'll leave you with that thought...
This has been brought up in this thread, I think, but the fact that
the visual aspect is more appealing to some people (especially those
who are non-programmers) is that one can see the paths the data flows.
Or at least they think they can because, in reality, in most patches
(beyond "hello world" stage) one can only a little bit at a time.
Yet, it is easier to see those connections then to make a mental image
of them. With experience we learn to see bigger but this visual
representation seem to be very helpful to some. Yet, as Dave (I
believe) pointed out, we are still typing symbols into those boxes.
It is no different (to me) than the hype about symbolic computing and
representing data and logic with symbols grouped by parenthesis in the
LISP programming language.
ciao for now
./MiS
Received on Thu Oct 15 2009 - 18:56:19 BST