| Bottom-Up
Bizet by Robert P. Taylor [Back
to Index] |
|
| Introduction  Computers are wonderful devices and
with them we accomplish wonderful, even astonishing things. But what astonishes me most is
the freshness which computing provides into what are essentially non-computing activities.
By identifying parallels with computing in a non-computing activity, I can often deepen my
appreciation and understanding of a familiar human enterprise, enriching my life
considerably in the process. I sometimes feel this may be a more significant reason for
getting involved with computing than is the whole business of getting the computer to
perform as a marvelously powerful and flexible tool in any of a host of scientific and
commercial enterprises. I do not feel most computing professionals take seriously enough
the importance of this "fringe benefit" of computing. In fact, I believe if we
systematically encouraged and publicized the application of such insights to significant
cultural enterprises, we would both enrich our culture and take a significant step toward
countering the growing popular misconception of computing as a mechanistic, dehumanizing
force in our society. The objective of this paper is to illustrate how this can be done in
terms of one well-established and sanctified art form in our culture, grand opera. It
should adequately suggest the merits of the idea.
Following this introduction, the remaining text of this paper is organized into five
parts. Part I review the origin of the paper and likens the production of opera generally,
and George Bizet's The Pearl Fishers in particular, to the implementation of a
software system. Part II likens the New York Lyric Opera Company (NYLOC), as it was
organized to produce the Pearl Fishers, to a software implementation team. Part
III examines the "documentation" normally available for implementing the Pearl
Fishers system and finds that it relates almost exclusively to the audio systems of
the overall opera system. Part IV, using the example of the lamination system, discusses
why and how all the video systems in the Pearl Fishers implementation project
developed their own temporary, make shift documentation. Part V draws several conclusions,
some about opera as system, some about the fruitfulness of extending the approach taken in
this article.
Drawing the Analogy Between Opera Production and System Implementation
I first became interested in the parallels between opera and systems while singing in a
recent New York Lyric Opera Company (NYLOC) production of Don Giovanni.
As we rehearsed and subsequently performed that opera, I was increasingly impressed
with the parallels between producing Don Giovanni and implementing a payroll or
other reasonably complex software system. Many of the structural relationships between the
personnel producing the opera closely resembled those characteristic of a good software
project team. Activities were modularized and were developed, tested, modified and
integrated just as the sub-components of a software system frequently are. Success in
producing the opera seemed to depend heavily upon fitting the different strands together
in the right place, at the right moment, much as the successful implementation of a
software system depends heavily upon interface definition and creation.
Long before opening night, I had begun to entertain myself in slack moments by trying
to look at the opera production as though it were a software system implementation. The
audience became end users. Cues became interfaces. Lighting and sets became sub-systems.
Section rehearsals became module testing. Rehearsals became debugging sessions. The dress
rehearsal became a pilot run. The voltage limitation in the lighting power source became a
hardware constraint. And on it went, until by the final curtain, I had come to see that
whole NYLOC production as merely the most recent implementation of the Don Giovanni
system.
It happened that I was teaching a course on systems analysis shortly after this
experience with Don Giovanni and I began to think that attending an opera rehearsal
might be a beneficial experience for the students in that class. After a few weeks of
introduction to systems concepts and an initial experience with the software system
development process, I felt the students might profit from the chance to try applying
these same concepts in a foreign context. There, because of the contextual freshness, the
concepts might emerge with greater clarity and the students return to the traditional
systems for the course with both a better understanding of systems concepts and a wider
appreciation of their grader implications. I suggested the idea to the class and they
decided it would be worth trying.
Experience with Don Giovanni strongly suggested that one opera would be just as
good as another for this sort of experience. NYLOC was, that term, reading Bizet’s The
Pearl Fishers for production so an evening dress rehearsal which coincided with the
systems class hour was selected for the class’s "night at the opera." Each
student was given the same assignment – to attend the rehearsal and to write up at
least one analogy which he or she discovers between opera "implementation" and
the systems work being studied in the course.
To prepare for the trip, the class was given certain written and printed material
concerning the opera, was required to listen to a recording of the latter half of Act II,
and was presented with a brief outline of the organizational structure of the New York
Lyric Opera Company. The materials and recording were focused on a dramatic climax in Act
II which involved extensive interaction of all the different personnel involved in the
opera production.
|
| The New York Lyric Opera Company as a Project Team |
 The organization of NYLOC is similar to the
organization of a software project team. Though soloists, their respective vocal coaches,
and individual singers and instrumentalists have been omitted to keep the size of the
organization manageable, the main structure is clear. There is a project leader with
overall responsibility (NYLOC General Director). Two sub-system leaders report to the
project leader: (1) the audio systems supervisor and (2) the video systems supervisor (the
conductor and director, respectively). The first has responsibility for everything the
user (audience) hears, the second, for everything the user sees. Each of these sub-system
leaders have both individual and lower sub-system leaders reporting to them. And, in
typical project fashion, each also assumes direct management for at least one sub-system. While
several of the sub-project or sub-system personnel under one or the other of these two
sub-project leaders have still other personnel reporting to them several others do not.
For example, the Group Vocal Systems Supervisor manages all the chorus personnel and is
responsible for the development of the entire choral sub-system. On the other hand, the
Lumination System is one person operation. This variety in responsibilities and in numbers
of upward-reporting personnel in each case is a typical project phenomena, depending upon
typical project realities – size of project and budget of project. In fact, the
tyranny of scheduled tends to make opera companies ideal models for project teams in at
least one major sense – the opera team must come up with an implemented system within
budget and on time.
Responsibilities are initially delegated to the various sub project leaders with enough
general discussion of interface details to enable them all to go ahead with their
individual tasks. Early rehearsals are then devoted to module or sub system design,
testing and debugging. Final rehearsals are reserved for integrating the modules and
sub-systems and thus resemble full-system testing. In this respect, the implementation of
the opera is a sort of bottom-up process. On the other hand, the very early rough
definition of interfaces between the various sub-systems and the constant dependence on
cues and stubs as modules are developed constitute a sort of top-down process. Thus, like
most system projects, opera implementation involves both top-down and bottom-up
approaches. |
|
| "Documentation" for the Pearl Fishers |
| The documentation presented here is but a minute sample from
the hundreds of pages existing for the Pearl Fishers system. For the systems
analysis class, excerpts of four kinds of documentation were presented: (1) overview (plot
summary), (2) narrative description (libretto), (3) audio systems vocal source code
listing (vocal score), and (4) user audio output sample (phonograph recording of
appropriate segments of system). Obviously no example of (4) can be included in a paper,
so none will be represented or discussed here. And, though an example of (3) is shown as
an opening illustration in Figure 1, this section will use the more complete audio systems
master source code listing which includes the vocal code and much more. (The master code
would have been used in class but it was unobtainable at the time.) In addition to
discussing the same aspects of documentation here as in the class, this section will
derive some unity from relating all examples to a single time-slice from the opera’s
execution. This time-slice is underscored in the overview excerpt presented in figure
3, and excerpt which adequately establishes the context for this time-slice. The systems
class studied several other time-slices and their respective documentation as well, but
space does not permit, nor necessity require more than this one time-slice to be examined
here. The opening illustration for this article, for example, presents video output
and an excerpt from the audio systems vocal source code listing relating to that
time slice when the lovers embrace. It should be noted, though, that these other time
slices would underscore what tremendous changes in the level of system activity occur as
the act moves from the moment of the lover’s embrace to a conclusion. The system must
shift from an intimate, dimly-lit love duet to a furious, full-company climax with every
character in the opera on stage and singing at full voice, with the orchestra playing at
full strength, and with the lumination system simulating a lightning storm.
Figure 4 clearly shows the peak of system activity as it is being halted
by Zurga’s entrance. This is a critical moment for interaction of the various
sub-systems. The extent to which documentation for the system details the interfacing
required to implement such interaction can be determined from examining appropriate
excerpts from that documentation. The appropriate segment from the narrative description
(libretto) is shown in Figure 5. The audio systems violin I source code listing
(concert master’s
part score) is shown in Figure 6. And the audio systems mater source code listing is
shown in Figure 7.  Since vocal code is included in the master
listing, since space is at a premium, and since the opening illustration, Figure 1,
includes a typical example of vocal source code, none is presented in this section. As
Figure 1 shows, no information on interfacing beyond that also carried in the master code
is carried in the vocal code. Its unique component, rather than interface information
generally, is the piano code which can be used during test runs to simulate or
"stub" in for the orchestra.
[Fig 7]
| Figure 3: Overview documentation Act II ruins of a temple. Nurabad, the high
priest, installs Leila in her position as priestess of the tribe. He tells her that she
must remain in silent watch and prayer throughout the night. She is fearful of the forest
sounds, but promises. Nurabad departs. As leila trembles at the roar of wild beasts, she
is suddenly reassured by the sound of a human voice. It is Nadir singing to her in the
distance. She answers, and Nadir, overjoyed, tells her of his love. They embrace, but are
surprised by the high priest, who has been in hiding. He calls the people together telling
them that their priestess has been false to her vows. The tribesmen are ready to slay her,
but Nadir shields her with his body. Zurga, in order to protect his friend, commands the
pearl fishers to disperse. Norabad tears away Leila’s veil, and Zurga then recognizes
her as the same woman over whom he and Nadir had formerly quarreled. A storm arises and
the people pray to the gods while the priests lead Leila away. Nadir is sentenced to
death. |
At the point where Zurga commands a stop (Arretez) to the
villagers' frenzied desire to slay the guilty couple, significant changes must occur. The
music must change from frenzied chorus to dramatic and isolated solo command. The activity
on stage must virtually halt. The lighting and orchestra sub-systems must create a sharp
change in mode. Figure 6 and Figure 7 demonstrate that the documentation carries extensive
interface detail for the audio system. The exact words of each singer, the exact pitches
and rhythms of each audio system performer's notes are clearly specified. The
dramatic change in mood is specified by the change in tempo at the double barline in both
source code listings' by the specification that every instrument and voice sound at full
strength, once and only once, at the change of tempo; and by the specification that Zurga
execute six notes in grand isolation immediately thereafter, while the instrumental
sub-system remains in a wait state. The exactness of this interface between audio
sub-systems is emphasized by the handwritten additions to documentation visible in both
Figure 6 and Figure 7.
[Fig. 6] However, audio sub-systems interaction is only one form of interaction in the Pearl
Fishers system. This scene certainly presupposes many decisions about interfaces
between lighting, stage settings, and singer movements. Yet the documentation presented
contains little or no specifications regarding such interfaces. We do find action
specification stubs such as ("Surga parait tout a coup au fond du theatre"),
in Figure 7, but these are little more than can be readily inferred from the larger
context provided by the singer's words. What the project team might most like to know is
not even mentioned. What are the villagers to do when Zurga makes his dramatic entrance?
What stage setting would maximize the impact of the entrance? Where should the guilty
couple be located when the entrance begins and where when it ends? How should the
lumination change during the critical moment? Not one of these questions is resolved in
any way by the "Zurga appears suddenly at stage rear."
Thus formal documentation for the system carries considerable detail concerning the
audio system but little concerning anything else. This is particularly noteworthy because
the documentation is so extensive. The audio systems master source code listing alone
runs to over 300 pages for the Pearl Fishers; the audio systems vocal source code
listing to over 200 pages; the narrative description to over 30 pages; and
the audio systems instrumental source code to over 15 volumes of 30 to 40 pages
each! |
|
| Make-Shift Documentation / A Product of Customization |
| In complete contrast to documentation for the audio system,
that for video is make-shift and varies widely from sub-system to sub-system. Each video
sub-system must go through a whole process of obtaining interface definitions; of
developing tailor-made documentation concerning these definitions and anything else
requiring common understanding across sub-systems; and of using the documentation to
implement its sub-system (note: this documentation may not even be written down at all).
Despite the differences between sub-systems, the salient elements in this process may be
grasped by looking at the example of any single, particular sub-systems are custom
components in every system which NYLOC implements. The remainder of this section is
therefore devoted to the example of the lumination subsystem in the NYLOC Pearl
Fishers implementation. The lumination system manger had 18 lights to use. One
could be used as a hand-held spot but all the others were mounted high out of reach and,
once adjusted for direction, could not be re-targeted without manually accessing them from
a ladder. Though the aim could not be dynamically altered during a run of the system,the
brightness of each light could be, since each was connected to a separate dial on the
lumination system dimmer panel.
Using this hardware, the lumination system manager based her creation of the Pearl
Fishers lumination on four things: (1) early conversations with the video systems
supervisor about his overall conceptualization of video output from the system; (2) her
own recollections of work on an earlier implementation of the Pearl Fishers at a
different site; (3) open-time opportunities to test each light in the system; and (4)
observation of preliminary test runs of this version of the system.
She used (1), (2), and (4) to create a catalogue of interface points where lumination
would help to define the interface both for other sub-systems and for the users. It
consisted of 34 entries describing the action occurring at the interface moment. The entry
for the dramatic moment discussed in the previous section is reproduced in Figure 8. 
She used (3) to number each light and create a table which would show, opposite the
number for each light, the target, color, and other salient characteristics of that light.
She then used this table and her catalogue during a final full-system test to create a
final catalogue of working interface descriptions for lumination. As with the preliminary
catalogue, this final one had 34 entries. This one, though, showed the exact lights to be
used for each interface and the exact brightness for each light. Entry 22 for this final
catalogue is reproduced in Figure 8. In that figure, the single digit numbers on the left
are light identification,the double digit numbers on the right are brightness
specifications.
It should be clear from this example just how customized this portion of the overall
system is. The physical constraints alone would vary considerably from one implementation
to another, rendering any but the most general interface documentation on lighting
useless. Moreover, as the examples from the audio system in the previous section showed,
there is no guidance as to where any of the singers should be on stage at any particular
time nor any exact specification of the sets which must provide the on-stage context for
these singers. Since all these would enter into decisions about which light should be
aimed where and when, no specifications of lumination could be meaningful without such
details about the other video sub-systems. |
|
| Conclusion |
| The discussion of the New York Lyric Opera Company as a
project team suggested that, like software implementation project, the production of an
opera involves a mixture of approaches, including both top-down and bottom-up procedures.
The discussion of documentation used in NYLOC’s implementation of Bizet’s Pearl
Fishers suggested that the opera implemented is a system which depends on both
off-the-shelf and custom components. It also suggested that the distribution of these two
component types very much followed the pattern suggested in the project analogy –
off-the-shelf components went into implementing the audio system and custom components
went into implementing the video system. This pattern existed because the audio system
depended on standard hardware (voices and instruments capable of standard output) while
the video system had to be built upon variables which changed with every implementation of
the system. What does all this suggest about opera and computing? Certainly that the
two activities have far more in common than popular stereotypes of either would imply. And
this article has examined only a few parallels – they are many more worth looking at.
Long range planning, debugging, backup procedures, and iterative problem solving would all
be interesting and would probably suggest further similarity between the two activities.
Those who like opera and like computing may wish to explore some of these other parallels.
What about the wider implications? For those who find opera of little interest, the
basic approach discussed in this article may be applied to other human activities. For
example, the systems analysis class undertook other assignments as well as the Pearl
Fishers one. They looked for parallels to system concepts in Defoe’s Robinson
Crusoe and turned up some very interesting ones. Then they went further afield and
looked for analogies in an activity of their own choice. The article they produce in that
final effort suggest the rich lode waiting to be mined. They found parallels to computing
systems work in such diverse enterprises as: incubating chicks, giving birth to a child,
learning to ski, playing a season of football, and preparing a family-reunion Thanksgiving
dinner.
Finally, whatever else one can say about this sort of pursuit of computing’s
fringe benefits, three things are clear. First, successfully calling attention to
parallels between computing and other significant human enterprises should weaken the
popular misconception that "computer people" engage in some sort of esoteric,
mechanistic enterprise, whose methodologies have no analogue in other human activities.
Second, it should also demonstrate one of computing’s most significant contributions
to general education -–it rewards the discovery of previously concealed similarities
and relationships. Third, the process of looking for such parallels is both instructive
and just plain fun!
[Back to Index] |
|
