Scribd
Upload
82 views2 pages

Harry-Ed Roland On Using Sound Loom

The document discusses Harry-Ed Roland's experience using the Sound Loom audio editing software, noting that while it was initially daunting, he has customized it to work as an extension of himself and finds it to be very user-friendly. Roland believes Sound Loom allows for a less visual approach that encourages listening over watching, and he has developed personalized systems for organizing hundreds of breakpoint files within various projects. Overall, he finds Sound Loom to be exceedingly transparent and more conducive to customization and automation than any other GUI he has used.

Uploaded by

jfk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as RTF, PDF, TXT or read online on Scribd
82 views2 pages

Harry-Ed Roland On Using Sound Loom

The document discusses Harry-Ed Roland's experience using the Sound Loom audio editing software, noting that while it was initially daunting, he has customized it to work as an extension of himself and finds it to be very user-friendly. Roland believes Sound Loom allows for a less visual approach that encourages listening over watching, and he has developed personalized systems for organizing hundreds of breakpoint files within various projects. Overall, he finds Sound Loom to be exceedingly transparent and more conducive to customization and automation than any other GUI he has used.

Uploaded by

jfk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as RTF, PDF, TXT or read online on Scribd
You are on page 1/ 2

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.

You might also like