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.