Republic Variantology

Republics can be structured in many different ways, and the present text 

discusses some known variants provide orientation for interested parties. 

Also, it contains a to-do list for making the discussed scenarios work better, see at bottom.

The potential elements for a Republic are 

Players (people) who typically have: 

one computer each (or at least terminal/control device) running:

SCLang (client)

maybe scsynth (sound server)

maybe loudspeakers 

Servers which may run on 

distributed, e.g. other players computers, 

or on a central computer, typically with a multichannel speaker system.

* Var1 - The simplest form, just connecting the Clients:

This can be done with SimpleRepublic.

All the sclangs know all sclang addresses, and can send messages, 

e.g. to share code with History, or to notify each other with Shout.

[Graphics - triangle of A, B, C, lines from lang <-> lang]

(PlayerC) PlayerA PlayerB (PlayerC)

lang <-> lang <-> lang <-> lang

server server server server

speaker speaker speaker speaker

* Var2 - connecting all clients and servers:

This can be done with Republic. 

All the sclangs know all sclang addresses, and can send messages, 

e.g. to share code with History, or to notify each other with Shout. 

All sclangs also know all server adresses, and can send synth messages 

to every server. This is done most easily with the RepublicServer class. 

[Graphics - triangle of A, B, C, lines from lang <-> lang, lang -> server]

as long as granular synthesis is used (i.e. one just sends synths that 

end by themselves, and never needs to access them again), this is 

possible without further complication. 

Using continuous synths and accessing them requires using separate nodeIDs 

for every client - this is already supported in the Server's nodeID allocation scheme. 

Using nodeproxies on any server requires a similar untangling of bus allocation 

Both of these are implemented in the SharedServer class, as well as non-overlapping 

buffer IDs.

Using soundfiles on other players servers would require some way of ensuring 

the files are in a known location. NOT DONE YET.

This seems cumbersome; a reasonable variant would be to agree on a set of 

soundfiles, put it on all computers in the same location, and preload all the buffers

on startup, so the buffer numbers are in sync across machines. 

* Var3 - Central democracy - many clients, one Big Server

All players play on one networked server, typically into a multichannel system. 

This requires the same infrastructure as Var2, and little else.

Spatialisation: all players simply route their sounds to any speakers they like.

Using nodeproxies on a shared server would allow for cross-connections; 

one could read other player's proxies, run them through one's own processing

and play them whatever fashion one likes. besides bus alloc. untangling, 

this would require knowing each other's proxies and bus IDs - NOT DONE YET.

Using soundfiles would best be done by preloading soundfiles locally on the server, 

and informing everyone of the available bufIDs (and maybe other buffer info). 

One could also provide uploading to a folder, with automatic load to buffer and 

info forwarding ...  NOT DONE YET.

* Var3a - many clients, one Big Server, separate Spat - e.g. WFS

Same as Var3, the only addition is splitting the available output busses to all players; 

then, each player can freely allocate her sounds to e.g. 8 out busses,

which are spatialized separately, e.g. on WFS, with Florian's SWonder class.

TO DO - ideally with importance and ease of realisation

1. When a SynthDef was added by using the SynthDef().share message, it is registered locally and sent to any newcomer. If the original author leaves the group however (by crash/sleep/out of room etc), a newcomer will not receive the synthdef, while all the others may still have it. 

Possible solutions:

everyone keeps every synthdef that has been shared by anyone

a newcomer receives all synthdefs:

* from everybody (using random delays): this may cause some overhead

* from one random person (usually this should be enough, but may fail in border cases)

2. ways to inform all clients of: 

buffers loaded on the central server 

proxies running on the different clients (and the central server)

3. ways to dynamically upload a soundfile, load it, and inform every client

4. building a server representation based on the currently running server: 

get all the proper server options ... 

maybe best from sclang on the server's computer!