On Sun, 2008-09-28 at 16:05 -0400, Darren Landrum wrote:
Paul Davis wrote:
To be honest, this is not an avenue that
interests me individually. I
view these tools as a lot like table saws, routers and jointers: things
with immense power that make a lot of tasks way faster and simpler than
they would otherwise be, but that do not remove the obligation to
develop a set of tool-specific skills. I've never had much interest in
designing table saws for people who don't want to know how to use table
saws, and I personally don't have a lot of interest in designing
software tools for people who don't want to learn how to use them.
Who said anything about not wanting to learn how to use table saws?
This seems a bad analogy to me. NI's plug-ins don't make me a better
musician. I still have to learn how to use them, but I don't have to
know how to code them myself first. That part's already done. I'm more
than willing to learn how to use a table saw, but I really don't feel
like building my own table saw first. Right now, audio on Linux really
does kinda force the latter, in my opinion.
if you use a language edited with text files and text editors, you're
going to have learn skills and concepts that are not directly related to
making organized sound.
if you use a visual language (pd, max etc), you will give up a little
bit of power, but not much. you will have learn quite a lot about the
fundamental concepts of those languages to be really powerful with
them.
i would equate either of those two tasks to learning to use a table saw.
and i say this as someone who lost half of his right thumb on a table
saw :)
what processing does (or so it appears to me) is to strip away some
significant elements of what pd or max offers but in turn makes the
learning curve less steep and high. if thats a good tradeoff for some
people, then rock on processing.
audio on linux doesn't force you to confront device driver HALs, or C++,
or even emacs. however, it does leave those options wide open if you
want to go down that route.
--p