1. Site and Schedule
The complexity of the such I2 connections suggests that we need to treat the event much the same as we would a major theatrical production with planning, preparation, rehearsals, technical rehearsal(s) and performance. From the experience of today, two technical rehearsals would be preferable. We did experience some additional difficulty when the Indiana site was moved to the library. It is hard to identify the source of feedback coming to New York, but it wasn't there on the rehearsal prior to the move (after the feedback had been debugged). We didn't have adequate time to trace the problem in the time right before performance when the feedback to NY became so pronounced. In addition, we were getting a very loud AC hum toward the end of the transmission, coming from Indiana.
We definitely need a fixed site where connections and equipment can remain in place. The space also needs to be appropriate for performances and for an audience. At NYU, we would have liked to use The Black Box Theatre, but we didn't have sufficient lead time, and BBT has serious security problems. Certainly the summer schedule affords a better time for more intense schedules and testing. The academic year does not provide many opportunities for such prolonged and intense use of theatre spaces.
2. Sound, microphones, headsets, speakers
The setup should be more on the order of a television studio with a recording studio design. Sophisticated configurations for headphones and monitoring sound can provide a much more satisfactory sound and make the musical result more successful. We needed more time during the setup to debug the source of distortion on the flute, which appeared to be a combination of mike placement, mixer control, and performer microphone style.
The advantage to the connection was that there was an audience only on the Indiana site. This enabled Gilfoy to add his sound as it was received in Indiana and provide a synchronized end result for that audience. In New York, the performers had to ignore the latency and the feedback to provide a coherent signal for Indiana. the fact that NY had percussion made it possible for that group to be synchronized with each other and also enabled them to ignore the feedback from Indiana. the fact that everyone involved as performers had recording studio background made it easier for them to adapt to the sonic distractions and stay focused.
Greater attention needs to be given to the placement of speakers and sound going to audiences versus sound going to performers. The rehearsals with Indiana did not take into account the sound for the audience.
3. Video
It was clear that the video display made it easier for the musicians to communicate, and Jack Gilfoy indicated that it was absolutely essential. In fact, he needed to see the percussionist at NY instead of the other performers so that he would have a visual cue as to the rhythm. Because we had a one camera setup, it made it impossible for us to zoom in and out on various musicians or other visuals in the studio. In a multimedia production with actors and dancers, it would essential to have a multi-camera setup and several video streams. One video stream would be dedicated as a visual monitor for the musicians. It might also be necessary to have such monitoring for singers, actors, dancers. Another stream could be one that is put together from several video cameras to provide an aesthetically significant video collage for the audience. This was somewhat the design of "The Madman and the Poet," the multimedia opera between NYU and RPI, except that the singers/actors did not have a visual monitor in which to respond to the work of each other but had to rely strictly on sound cues.
In Studio E, we projected Jack Gilfoy at the end opposite the NYU trio. It made a very practical arrangement where the performers could include Jack as part of the ensemble.
4. Latency and Feedback
Every interactive connection over distances will have latency problems. Latency should really be built into the content, but there is no reason to put up with inadvertent feedback. i\In the first I2 connection, a year ago, we broadcast from Innovation Center using Windows machines with built-in codec equipment. We had absolutely no feedback problems, and latency was negligible. There we were dealing with music coming from NY and no musicians in Indiana. However, the Q&A session and discussion was very clear and the spontaneity was almost like being in the same room. In the November exchange and this exchange, feedback seemed to add to the latency problem. It also affected the Q&A session.
We need to give more time to testing the feedback loops and latency factors. We did give some time and effort to eliminating the feedback through technical debugging, but the feedback crept back in from the Indiana side (or NY, or both?) on the day of the performance, and there just wasn't time to resolve the problem.
In music of the past, music in cathedrals also had a kind of latency problem in the delay of sound. This affected the way music was composed and structured, including the elaborate antiphonal schemes that emerged. Certainly, we can incorporate the phenomenon of latency into the performance. This was handled beautifully in "The Madman and The Poet" although the latency was negligible since we were transmitting for about 140 miles.
Many of the structural schemes developed for the Cassandra and Orpheus (Dinu Ghezzo, John Gilbert, Alistair Martin-Smith, Lisa Naugle, et al.) projects have included latency as part of the content. Precise rhythmic ideas become one-way transmissions. Two-way+ transmissions allow for slippage so that textures are emphasized over rhythmic precision.