[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Date Index][Thread Index][Author Index]

What it means to build vs. play...

Rick and dcoffin's comments make me want to put this thread into a
slightky broader perspective...

I used this analogy before, but it's the best one I can think of:
learning to play an instrument is basically the process of learning to
work within a fixed set of parameters.  And if someone has designed a
truly deep and elegant instrument, then the player can find more and
more inspiration within it as their understanding of the instrument

There's a depth of understanding and experience that a Leo Fender, Ned
Steinberger, Paul Reed Smith, or Uli Teuffel will have about how to make
a guitar that isn't going to be present in someone who's just starting 
to build them.  

Likewise, there's a collection of thought, experience, vision, and
imagination in hardware that Matthias Grob, Kim Flint, Claude Voit, Andy
Butler, Chris Muir, and others have contributed to for over ten years,
that isn't going to be present in someone who's just starting to
assemble modules in a software package.

So to me, the real difference between playing a hardware instrument vs.
building a software one isn't just a question of, "Can you do in
software what you can do in hardware?"  It's more a matter of what kind
of relationship you want to have with your tools.

I like being presented with an instrument that's already been designed,
by guys who have thought about the concepts much longer and more deeply
than a person who's just getting started with it.  I like the experience
of developing mental and physical technique to bend the instrument to my

I like knowing that there are certain things I can do with an
instrument, and certain things I can't, because it means I can spend
less time trying to decide what I should play, and more time exploring
the concrete territory within one fixed and tightly-defined vision.  And
it's always fun when those "things I can't do" start to become "things I
CAN do" as a result of honing my abilities, and my understanding of the
instrument, with time and experience.

And I love the sense of discovery when I suddenly start
understanding the brilliance of features and design aspects that I never
understood or found interesting a few years ago... and then I realize
just how far ahead of everyone else the guys were when they designed it
in the first place.

dcoffin@taunton.com wrote:

> Frankly, a commercial looping-only product

Is "commercial looping-only product" an oxymoron?  ;)

> tangled up with complex
> features behind a cryptic and fixed interface, 

The EDP's interface is actually very deliberately laid out along the
front panel, and there are very deep reasons why the functions and
parameters are organized the way that they are.  If you take the time to
work from left to right, and get a sense of the basic principles that
the unit is based on, then the supposedly complex and cryptic instrument
starts to make a lot of sense.  In fact, it actually becomes very, very
intuitive.  And the interface was laid out in a specific way precisely
because the designers felt it best reflected their vision for their 

I seriouly doubt that a programming system like Reaktor or Max/MSP could
be completely understood in just a few hours, or even a few months.  Just
like the EDP, each of these programs have a specific design
architecture, and if you want to truly understand where they're coming
from and how to use them, you have to spend the time learning them.

> designed
> by somebody else to suit a broad audience using preconceptions about
> looping and concepts for looping features that didn't come from my 
> and fantasies and have to be deciphered to be made my own 

I would have to say the following:

- The concepts within the EDP are some of the most singular,
ideosyncratic and unique ones you'll find, and were designed by guys who
have spent DECADES thinking about looping and how to go about
implementing it in an elegant and intuitive manner.

- Things like unrounded multiply, SUS-functions, function quantization,
and the like are hardly tailor-made to a "lowest common denominator"
audience, and they utterly fly in the face of most people's ideas of
what they look for in looping.  I'm not just talking about the LoopIV
upgrade; there are things in the original software from 10 years ago
that people are still barely coming to terms with.

> So, for me, it isn't a question of when software will match hardware, or
> can it?...it's do I even NEED the hardware anymore?

I guess it depends on these issues:

- Do you need a basic underlying software that's the product of decades
of collective experience, testing, debugging, and imagination?  With a
depth of focus and intent that comes from focusing its parameters on one
specific task, with some features that won't fully reveal themselves
until after several years worth of study?

- Do you need an interface that's been carefully designed to offer a
fluid and intuitive PERFORMANCE experience?  Being "real-time" and being
"performance-friendly" are not necessarily the same thing at all.

- Do you need to do things in software that you know you can't do in
hardware?  And could there be things in hardware that you wouldn't have
thought of, that could end up sparking your imagination if you take the
time to work with them and accept the "limitatons" they're presented in?

Finally, Rick Walker said:

> It doesn't have to negate an artist who just can't wait to get and master
> the latest mangling plugin software.     Two different instruments.  Two
> different musicians...............Viva la difference!

Negating someone else's work is absolutely NOT what I'm about.  If
someone absolutely loves working with Max/MSP or Reaktor, then that's
what they should do.

But in order to "viva la difference," I think you have to UNDERSTAND "la
difference" in the first place.  And to me, that's what all of this is
about: thinking critically so we can get to the heart of what those
differences mean to people, and how they might impact the way we work.


--Andre LaFosse
The Echoplex Analysis Pages: