>> A graphical layout is great for expressing relations and
> structures and less so for expressing calculation order, which can be
> very important in sequencing.
good point, The cables were usually where the sound flowed along, so you
could determine chains of events on a single path, but not in any
sensible sequencing of events over time. The cabling out of my desk was
almost always 'post processing' in some ways..
I think this is well reflected in pd, where sequencing is one of the
things that seems less natural for it and takes much longer setup than
processing dps streams does.
on a side note has anyone used vvvv much?
its use of 'slices' is kind of interesting, it allows you to generate
and process multiple instances of almost any sort of message in and our
of any object. Its like a inbuilt iteration or something. Im guessing
its one of the ways a 'graph' programming system can overcome the
spagetti of multiple modification in recursion etc or the issue of
generating new objects on the fly (which text languages excel at, but
graphical ones seem less keen)
Tom Betts
----------------------
www.nullpointer.co.uk
www.odessadesign.co.uk
----------------------
Kassen wrote:
> Tom;
>
>
> 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..
>
>
> I find the analogy works in some places and not in others. I patched
> graphically/physically for quite a while before getting into coding and
> found it works very well for sound design and less so for logical
> structures. A graphical layout is great for expressing relations and
> structures and less so for expressing calculation order, which can be
> very important in sequencing. I think ChucK picks a interesting middle
> ground there, using code with visual analogies to express signal flow.
>
> Considder;
> //this is basically a diagram that is also code
> SawOsc my_signal => LPF my_filter => ADSR my_envelope => dac;
>
> Note that this "diagram", like any other line of code, will construct a
> patch at a moment depending on where it occurs in the code, creating
> both a visual analogy for the signal flow as well as the chance to
> express calculation order precisely. Also note we may use "modules" of a
> type that depends on conditions, something not easily expressed in pure
> diagrams.
>
> Yours,
> Kas.
>
>
> ------------------------------------------------------------------------
>
>
> 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 - 17:38:26 BST