Harry-Ed Roland on Using Sound Loom
Before I go on, I'd like to categorically state that I am not a
programmer/developer but a musician, who actually hates computers and
thinks the concept of 'user-friendly' is just hog-wash, to put it mildly.
Every program/platform has its own learning curve, none are ergonomic, and
I'm not certain if there's any getting around it (keyboards/mouses. . . .what's
the difference?), irrespective of who designs the interfaces/tools.
I also have to admit that SOUNDLOOM was daunting, the first time I tried it,
although I had had years and years of working with the CDP programs
(concepts). Now, however, it's like an extension of me, like before, with
commandlines and my batchfiles, it's like my own private tool. Now, THAT is
user friendly (a tool which you can make private).
I've not found the clicking around cumbersome or awkward. A double-click
will play the sounds from nearly everywhere, except the process page. And
your playback program (which you can freely select) will determine how play
is stopped. I often use ctrl-F4 to simply close the play-back window, when
I've heard enough; I've otherwise set it to close automatically after playing
the file once. I also use markers to repeat sections or to have a recurring
starting point (other than the beginning).
I also believe, RELIGIOUSLY, that the less 'visual' sound_design programs
are, the more prone one is to listen to the results, as opposed to thinking
about them or creating 'nice' pictures/or ideas of how things SHOULD be. . .
fades being a perfect example. My playback program, for example, is set to
only show a time-line. My pieces are also tighter since I've stopped
'watching' them play and I am less exhausted, that is, can work longer.
I've managed designing breakpoint files extremely well by examining a
graphic representation of the sound, making note of points (times) where
manipulation is desired and designing the breakpoint files with this
information, so that the visualization_program is comfortably separate from
the actual design process.
It should also be mentioned that I have hundreds and hundreds of
breakpoint files (years worth), organized in several systems which allow me
to hide, alter, recycle and reintroduce them, at will. As this is one of my
principle tools, it was critical to have a personalized system, one with which
I'm thoroughly pleased.
I think it particularly crucial to have an HTML user guide for the individual
processes open and available at all times, for simple reference, as it is
impossible to remember the parameters and ranges for such a vast number
of processes. Having said that, I've discovered that the preset parameters
are particularly useful as a starting point. Saving a chosen set(s) of
customized parameters and starting the process anew, by loading them, is
the ultimate way-to-go, my tried and proven method.
Saving those files in a project folder, so that they are only available in
successive projects when directly introduced (copied into that project's
folder), helps to avoid clutter. It is also extremely important to name the
set-files/batch-files in a manner which makes it explicit which process is
intended/was originally used.
The very fact of being able to choose potentially 'out of range' or impractical
parameters is one of the strengths of SOUNDLOOM. Those
programs/programmers which presume to know what 'makes sense' and
prohibits all else are simply presumptuous and, tend, ultimately to be
straight-jacketing, rather than helpful, in the long run.
The soundloom concept, once you get used to it, is EXCEEDINGLY
transparent and more conducive to customizing and even automating
processes than any GUI I have ever used. The instruments, remembering
last used process and parameters, batchfiles, etc. have allowed me to be
faster, systematized, more consistent and personalized than I could possibly
ever be, irrespective of how many hot-keys were/are implemented.
"Grabbing a sound file" is more than "drag-drop", if -- for example -- I want
to search for files with generic names or for files in a log.
I'd also like to mention that I know of no other software, where, when the
programmer is sent a bug notice, it gets removed "during your life-time" or
at least while you're working on the same project.
