Performances

This page is about collaborative performance support.

See also: Performance Parameter Change and Race Conditions

A performance will be opened in a window similar to the project editor, but with some GUI difference (maybe a background color) indicating we are in “performing mode” instead of “project editing mode.”

Since the goal is to perform instead of edit, the performance should NOT be edited (but there is no lock to prevent it). The module parameters can be changed via OSC. After a performance, no changes will be saved (next time it’s still going to be opened in the initial, default setting).

A performance can be created or joined by opening a project from the project listing page. The user is prompted for a new performance name or an existing performance name to join.

OSC control: the biggest feature of a performance is that it allows multiple performances to be opened simultaneously on the same server and receive OSC messages that don't interfere with each other. This is achieved by:

• Performances are stored temporarily in the database. (4 weeks?) So once you create a performance and give it a name, you can return to and “join” the performance, keeping the same port numbers.

• The server keeps track of active performances. When everyone leaves a performance, the server needs to close all the associated ports.

• The database keeps a table of all ports that are assigned to any performance. When a performance expires (after 4 weeks), the performance ports are removed from the database port table.

• When a performance is created, the server assigns port numbers to every module with OSC control. These port numbers must not conflict with any other performance whether it is active or not. Ports should be from the range 49152–65535.

Limitations:

• In the current implementation, there is no actual restriction on editing performances, but any edits are local only and not seen by others, allowing performances to behave differently even under shared OSC control.

• To achieve shared editing, the original project must be edited and a new performance created, which reassigns port numbers and requires every performer to update their OSC device. Painful and could be improved by:

  • Allowing a kind of performance update where you save the edited performance under the same name and retaining the assigned ports.
  • Actual shared editing, which is really tricky because of race conditions: what if there are conflicting connections? Both are made locally, so one has to be "backed out" or "rolled back" like a transaction.

• This implementation will limit the creation of new performances when ports run out, even if most ports are not actually in use. This can be addressed by:

  • Allow performances to have conflicting ports. When a performance starts, ports may have to be reassigned and users will have to be notified to update their mobile device settings.
  • Eliminate OSC and build apps using mobile device browsers and web sockets.

Demo (Expected behavior):

• A project is created and saved with patching.
• Group A creates a performance copy of the project, assigns the ports and controls.
• (Simultaneously) Group B create another performance copy of the project, registers several devices IP for modules, and controls.
• After the performance is done, no parameter changes get saved.
• Subsequently (before the performance expires), the same performers can reopen their performance and use the same ports settings for control.

Plan

• Beginning of March: implement and test
• End of March: draft of Kristin's thesis

Deliverables

• Support collaborative performance: multiple players (at least 3), OSC control, and parameter changes are distributed to all players. Demo concert
• Report - 5 to 10 pages, explain
  • Overview of soundcool
  • Summary of different architectural approaches (single soundcool app + zoom + incoming OSC, multiple soundcool apps + OSC bridge app to duplicate OSC messages (peer-to-peer approach), multiple soundcool web audio pages + server to duplicate/distribute OSC and control info)
  • Description of the implementation
  • Measurements: latency estimates, maybe survey players
  • Conclusions