THEATRE DESIGN & TECHNOLOGY MAGAZINE

1988 WINTER ISSUE - SOUND COLUMN

A SOUND FUTURE (PART 1)

By Charlie Richmond 

Share with me a dilemma for a moment, and then let me know if I'm
lost in the reverb.  Sound designers have been waiting for a long
time for a system which allows us to create soundscapes easily,
almost intuitively:  a system which would perform as a
transparent extension of our desires, a tool which requires no
interpretation between wish and result.

Of necessity, such a system would incorporate a device commonly
known as a computer, although certainly in a more 'transparent'
form than the one computers have generally taken for the last 20
years; most artists don't usually find expression easy through a
computer keyboard.  I have been watching with intense curiosity
the many forms that the most commonly computerized theatre design
area has been taking.  Computerized lighting has developed into a
very powerful and reliable technology, yet incorporates somewhat
less than current computer capabilities.  My perception is that
this is a result of the continued use of certain conventions
which were established during the earlier years of more primitive
operating systems.

Obviously people are hard at work developing new approaches but
it still remains curious that the most exciting aspects of the
more advanced systems have not been embraced.  One of these is
the concept of 'What You See Is What You Get' (WYSIWYG)
exemplified by the current explosion of desktop publishing
software.  Or maybe there's a reason for this:  just exactly what
is it you are 'getting' when sound is designed?  For example,
just exactly how are you going to graphically show a cue 'going'
or, more basically, a tape deck starting or a loudspeaker
switching on?  Perhaps those are too easy:  just point at the
picture of the deck and click the mouse button and the
(graphically represented) reels will start turning, click again
and they will stop.  Great, but what it it's a cart machine, and
what about all the different types of loudspeakers?  All of a
sudden, I start seeing a lot of work for our software people and
a delivery date of some time in the 1990's for a customized
system.  So, we end up with something in between.

If we accept that the ideal is still unobtainable (or more
properly stated unaffordable), just where is the happy medium
between cost and a system which genuinely improves the designer's
productivity?  Looking again at lighting, it seems that graphics
are being under utilized by most current systems.  For example,
given the relatively small number of different types of
instruments, it seems that a menu of types, graphically
displayed, could be available to assign to dimmers or patch
circuits so that the designer (or operator) could quickly see
(and select) the complement of instruments within cues.  Colour
also, is an extremely important element in lighting, yet no one
seems to use colour capabilities to identify circuit, dimmer, or
cue colour characteristics.  Finally, since lighting is an
essentially visual medium, it seems that endless possibilities
exist within the display capabilities of the video monitor.

The most comprehensive possibility might be the mocking up of the
stage set on the video monitor and then programming the show by
'lighting' it on the monitor.  While we're at it, let's put
moving actors on and provide views from different seating
positions.  Actually, considering the cost of some of the
lighting systems, such a situation is certainly not out of the
question!  What does this have to do with sound, you ask?  I am
using this illustration as an example so that you can answer for
me (and for yourself) 'What is the sound designer's version of
this?'  I'm not really sure of the detailed answer, although it
would require a very comprehensive multichannel sound system with
plenty of digital electronics.  It would certainly be a more
expensive system than the one the designer has available in the
theatre and would require more complex software to create an
artificial acoustical environment.
 
Referring to lighting again, I find it increasingly curious that
numerals alone continue to be used to represent the levels of
hundreds of dimmers.  Posed with a similar requirement but using
a larger amount of data by a factor of ten, a sea of numbers
swimming around the screen seemed to be a very non-intuitive way
of presenting a tremendous amount of information.  Why not use
small graphic representations of common audio devices such as
faders and switches to quickly show the relative levels and
settings of many channels simultaneously?  Then we could allow
the user to quickly select one of these for more detailed
observation, a bit like a magnifying glass.  But switches and
faders are only the physical entities which have been previously
used to create electronic responses to our wishes.  Perhaps there
is a more graphic manner of expressing 'increase volume' and
'switch this on.'

In the theatre we want to be able to send any audio source to any
combination of outputs at varying volume levels in such a manner
as a giant matrix allows.  Maybe we should be able to display a
big picture of the loudspeaker representing the output in which
we want to increase the volume.  We could represent the overall
volume of the loudspeaker by changing the overall size (volume!)
of the graphic representation.  But we actually have many
different sound sources, from microphones to tape decks, being
sent to this loudspeaker.  Maybe we could show smaller pictures
of the sources inside the loudspeaker and change their size to
indicate their relative volumes.  Conversely, we could show a
large picture of a source, say a specific microphone, and inside
it representations of all the different loudspeakers to which it
is being sent.  Then we could change the overall volume/size of
that source as well as the volume/size of the loudspeakers show
within it.

Great.  Of course we would have to include numbers or labels
inside each of these pictures just to make sure everything is
being correctly identified.  Also, any change made to a specific
loudspeaker volume from within the mic picture must be
correspondingly adjusted for the microphone volume within the
specific loudspeaker graphic.  All of this is technically
feasible right now, so if you're thinking 'Why hasn't someone
done this?' the answer is easy:  money . . . and a few other
problems.  For example, how do we tell the computer which of the
many pictures we want to see and focus on and how should they all
be organized spatially?  Also, how do we handle a myriad of other
functions which start cropping up as soon as we start designing
one cue after another and want to put them in a logical order,
edit them, and provide smoothly timed transitions between them?

All of these problems could be dealt with through graphic
solutions similar to the above exercise, but the fact remains tat
this is very much uncharted territory and is a considerably more
difficult program to write than normal.  The fact that theatre
people are by nature creative and innovative makes me feel
hopeful that we will provide important developments in the areas
of human/machine interface, especially now that such incredibly
powerful graphic based microcomputer systems are becoming
commonplace.

In the meantime, I have to say that my own solution to the
immediate problem is one of basic expediency:  a computer based
graphic representation of a virtual control panel of enormous
proportions (considerably larger than any physical console one
would want to control) in order that a very large number of
inputs and outputs can be completely manipulated.  Volumes are
controlled by faders and switches look like switches, but who
knows what the next incarnation of the software will be?  The
most incredible aspect of software-based systems is that the
computer and its programming can be updated or replaced
completely, giving the designer and operator the feeling of a
brand new system, yet the hardware may not need any alteration
whatsoever!  I really feel we have finally arrived at the future.

Let's hear from you if you have any ideas on this subject.  In my
next column I want to deal with the other end of the
human/machine interface, i.e. not how the computer tells the
designer what it's doing but how the designer tells the computer
what to do.

----------------------------------------

Copyright ©1987 Charlie Richmond