Multi-client Setups:
Filter:
Guides | Server > Architecture | Tutorials

Multi-client Setups

How to set up and shared servers for multiple clients in SuperCollider
  

Multi client-server setups - discussion and tests

OSC communication between SC and its sound server offers many options for network music: Multiple computers can run both supercollider and associated sound servers. For clarity, the "server process" refers to a running scsynth or supernova process. The "server object" AKA "client" is the server's representation in sclang, such as Server.local, s, Server(\elsewhere, NetAddr("163.234.56.78")).

What are clientIDs, and how do servers get them?

When more than one user plays on a given server, some resources need to be shared between users/clients:

This sharing is handled by declaring how many clients/users are expected to login - server.options.maxLogins - and scsynth will automatically give a different clientID to each client when it logs in.

The most common case is that there is only a single user/client, who always gets clientID 0, and control of all available resources (i.e. the full number range of every allocator).

When multiple clients log in, this is what happens:

Code examples and tests

Recommended usage for multiple clients on the same server is to use identical options settings for all clients, and logging into the scsynth process from different sclang instances, which are typically on different laptops.

When fixed clientIDs for multiclient setups are desired, the recommended usage is to set every clientID on creation.

Separate defaultGroups

For info on what a default group is, see Default Group.

Every client registering with a server has its own defaultGroup. All nodes belonging to one client are in its defaultGroup and can be specifically addressed, so that a client can release only one's own nodes, and leave those of other clients on this server untouched.

A client also knows the defaultGroups of all other clients that may login, so it can reason about other clients, and be as sharing-friendly as desired, see below in subsection CmdPeriod behavior.

s.defaultGroups;

Easy-to-trace nodeIDs

For details on node allocation, see NodeIDAllocator and ReadableNodeIDAllocator class and help files. The scheme from NodeIDAllocator is also followed by many non-sclang clients allocation ranges; in networks with these, NodeIDAllocator will be the safe choice.

Bus channel and buffer numbers

The allocators for audio and control busses and for buffers split the full number range of scsynth evenly for the number of clients expected.

Buffer allocation uses the same class, ContiguousBlockAllocator, and thus works the same way.

Configuring CmdPeriod behavior

In networked performances, it is useful that clients have well-chosen emergency access to 'their' sounds on a remote server; and it may make sense to give the local client more emergency power. Both can be configured easily.

Default behavior

By default, the local client will kill all sounds, and only reconstruct its defaultGroup; on remote clients, CmdPeriod does not affect remoter servers at all.

Remote-friendly local master setup

Now, all sounds on the server are gone, as desired. But the other clients cannot start new synths now, because their defaultGroups are gone too!

Thus, the local client should reconstruct them, so the other clients can pick up playing again:

Give remote clients control of their sounds

More power to all

In a less polite symmetrical setup, CmdPeriod stops all sounds on all clients, but keeps all defaultGroups running.