What musical activities can locked down musicians do via video-conferencing?

Question

The UK Brass Band I play with has already hosted one on-line meeting for our locked down brass players (via Zoom).

It was immediately apparent that timing latency makes it impossible for us all to perform together as though we were all in the same room. So we can't play pieces together.

But we can do exercises. If we were all in the same room, this is the sort of thing we might do:

• breathing exercises
• scales and intervals
• lip slurs
• copying back a played phrase
• watching the conductor
• improvising over a held chord
• listening for intonation
• fingering patterns
• stylistic techniques, e.g. how to swing
• etc.

When I physically stand in front of an ensemble my ears tell me which players are OK with what they've been asked to do, and who might need extra explanation/encouragement. But in video conferencing, the sound is mono, so everyone's sound comes from one point in space. It's much harder to know who needs the explanation/encouragement. So mono sound is another limitation of video conferencing.

My question is - what useful exercises can a group of musicians in lockdown do that still work despite timing latency and mono soundfield?

Answer 1

As a preface, my experience playing duets via Zoom is that in addition to the latency, Zoom doesn't handle the simultaneous sounds well -- I can hear myself or my partner, but not both.

That said, a few experiments you could try:

1. IF the latency between each instrumentalist and the conductor is close enough to the same, the conductor can conduct as usual, and to each player, it will seem they are in time. The burden falls to the conductor to stay consistently ahead of the beat (and therefore out of sync with the heard performance). It might be necessary for each performer to turn off their own speakers.

2. Try arranging or creating some music that incorporates phasing, and therefore might even benefit from the latency. This would be highly non-traditional as far as brass band repertoire, but could be a fun, experimental way to incorporate the kinds of exercises you describe above. For example, take a look/listen to "In C" by Terry Riley

or any of Steve Reich's "phasing" pieces, such as

)

The pieces I mention depend on rhythmic exactness, so you wouldn't be able to play them as intended, but the latency problem might allow you to catch the spirit of them in interesting ways.

3. Have one musician improvise a short musical segment or phrase and have each band member in succession pick up the idea and continue or develop it in some way. Latency would probably create awkward rhythmic breaks between each musician, but since the primary exercise is one of listening and being musically creative, the breaks between phrases might be not only tolerable, but necessary.

4. Picking up on that idea, you could try a game of "operator". Only two musicians communicate at a time, with everyone else turning off their speakers. Musician #1 plays a musical idea — maybe from a piece you're rehearsing, maybe improvised — to Musician #2. Musician #1 turns speakers off and Musician #3 turns them on. And so forth until you come back to Musician #1 to see if the phrase has maintained correct notes, rhythm, tempo, dynamics, etc. No cheating by watching to see what fingering is being used.

5. A "Watching the conductor" exercise / game: The conductor conducts and everyone else tries to guess which piece (or section thereof) is being conducted. Good practice for both conductor and band!

Answer 2

Just seen that question, so I am years late to the game. It still makes sense to put an answer here because, well, the pandemic is not over to the degree where it will not significantly affect attendance, and even after that there are reasons for remote practice.

We've practised throughout the hard lockdown in our country (about half a year) using Jamulus, free software with a long history (at one point of time, it used to be called llcon instead). It uses a centralised server architecture focused around UDP packaging of Opus-encoded data (these days, WebRTC might make more sense), where the server is responsible for creating the individual mixes (everyone has their own mixer for managing the sources) and sending them out again.

Since it is audio-only, integrating a conductor requires some imagination. The central server should be in "network vicinity" to the clients (which can mean that it may be better situated near a network interconnection point 100km away than in the same town as the participants) and have sufficient power for handling all the clients. If you don't want to depend on a public server, renting an on-demand server of sufficient power and connectivity will make sense because they tend to have better connectivity than a private user.

Running the server is what requires technical savvy (Linux offers itself), setting up the clients (Windows, Linux, MacOSX, by now also iOS and Android) is somewhat straightforward, but low-latency setups (avoiding WiFi, preferring soundcards that can reach low latency, typically ruling out bidirectional USB microphones that would otherwise be perfect) do warrant some experience. Note that a traveling expert can provide help here in one-on-one scenarios that are less problematic than group settings regarding pandemic safety measures.

For fast pieces and mixed user latencies it may be helpful if someone will inject a fixed rhythm from an arranger keyboard or a similar "deaf drummer" contraption: that helps avoid "creeping slowdown". Headphones are mandatory since echo compensation is not done for speed/efficiency reasons.

The individual tracks can be recorded on the server and a mix generated and distributed from it afterwards: voice separation is much better than can be achieved in a live setting which may make this a helpful tool outside of pandemic reasons.

For getting your feet wet, it can be easiest to start installing a client, then connecting to some public jam session on a public server. Be sure to have read up on stuff well enough not to disrupt the session if you can avoid it. Developers and users tend to be friendly, however.

A different software would be "Sonobus" which has a peer-to-peer architecture and consequently has increasing network and performance requirements for every client as the number of users grows: for Jamulus only the server needs to scale up to the number of users regarding network and processing power.

Some people claim to get along better with JamKazam particularly regarding the complexity of the setup, however it requires working with a central server that has a fee scheme for membership.

All of those solutions are audio-only. For some public Jamulus sessions it is not uncommon to have a Jitsi session for video only in parallel, but in my experience it affects the audio network performance too much to be really desirable.

Answer 3

The bandmaster could play (alone or with a small ensemble) a piece in his style and make a video that shows him conducting and giving the accents, fermatas etc. Each member can play at home his part to the video just when he wants to practice.