1title:: Client vs Server
2summary:: Client versus Server Architecture and Operations
3categories:: Server>Architecture, External Control>OSC
4
5The name "SuperCollider" is in fact used to indicate five different things (Figure 1):
6numberedlist::
7## an audio server
8## an audio programming language
9## an interpreter for the language, i.e. a program able to interpret it
10## the interpreter program as a client for the server
11## the application including the two programs and providing mentioned functionalities
12::
13
14image::structureEn.png#Figure 1. Structure of the SuperCollider application::
15
16The SuperCollider application is thus made up of two distinct, autonomous, components, a server and a client. For the first we have a choice between scsynth (SC-synthesizer) and supernova, and for the second we have sclang (SC-language).
17
18section:: Description
19
20The SuperCollider application makes use of client/server architecture which separates two functions, respectively one providing and the other requesting services. The client and the server communicate through a network.
21
22image::s8kfFC-clientServerEn.png#Figure 2. Client/Server architecture::
23
24In Figure 2 a generic network architecture is depicted: A number of clients communicating with a server by exchanging messages through a network. In SuperCollider the client and the server make use of a specific subset of CNMAT's Open Sound Control (OSC) protocol in order to communicate (over TCP or UDP). As a consequence, you will see many references to "OSC messages" in the help files.
25
26To avoid any possible confusion: The network is defined at an abstract level. This means that the client(s) and the server(s) can be in execution on the same physical machine. This is what normally happens when you use the SuperCollider application: two programs will run on your machine, scsynth (or supernova) and sclang.
27
28The server app, emphasis::scsynth:: or emphasis::supernova::, is a lean and efficient command line program dedicated to audio synthesis and processing. It knows nothing about SC code, objects, Object Oriented Programming, or anything else to do with the SC language.
29
30The client of this server is emphasis::sclang::. Sclang performs two distinct tasks:
31definitionList::
32## Client || it is the emphasis::client:: for the server, i.e. it sends OSC messages to the server.
33In order to write a letter to server, you need a paper sheet and a mailer: sclang is both.
34## Interpreter || it is the emphasis::interpreter:: for the SuperCollider programming language, i.e. it allows to the user to write code in the aforementioned language and interactively execute the resulting commands, e.g. to control the audio server. In particular OSC messages can be cumbersome to write, as they share with the server its low-level perspective. The SuperCollider language is a high-level, fully featured object oriented language, allowing the user to gain a much more expressive power than OSC messages. Typically, the interpreter translates the code in SuperCollider language in OSC messages for the server. The user writes poetry (so to speak) in the SuperCollider language which is then paraphrased in OSC prose by the sclang interpreter, to be sent to the server.
35::
36
37From inside sclang, starting a server app can be accomplished by:
38code::
39s = Server.default; // create a new Server object and assign it to variable s
40s.boot;             // boot the server app, i.e. tell the server to be ready to work
41::
42The sclang interpreter can send OSC messages to the server in two fashions:
43definitionList::
44## directly || in this case, sclang offers a thin syntax layer which allows one to deal with raw OSC messages. All the server's functionality is in this case available "by hand" using the .sendMsg method of link::Classes/Server::, and other similar messages.
45code::
46n = s.nextNodeID;                   // get an available nodeID from the server and assign it to n
47s.sendMsg("/s_new", "default", n);  // use the SynthDef "default" to create a synth with ID n
48s.sendMsg("/n_free", n);            // release the synth n
49::
50## indirectly || the language app provides you with convenient OOP functionality to keep track of and manipulate things on the server. The high-level syntax is translated into low-level OSC messages by sclang and sent to the server (language wrapping).
51code::
52x = Synth("default");   // create a synth on the default server (s) and allocate an ID for it
53x.free;                 // free the synth, its ID and resources
54::
55::
56Working this way you have gained certain functionality. It provides a node ID for you automatically, it allows you to control the Synth in syntactically elegant and efficient ways (see the link::Classes/Synth:: and link::Classes/Node:: helpfiles), and to access all the advantages of object oriented programming while doing so.  Encapsulating the complexities and bookkeeping greatly reduces the chance of bugs in your own code.
57
58image::scEn.png#Figure 3. Sclang as a high-level client::
59
60Language wrapping allows the user to access complex behaviours from very little code. Figure 3 (ignore for the moment that sclang is represented as a client among other possible ones, see later) schematically represents what happens when you evaluate an audio function like this:
61code::
62// assuming the server is already booted
63{SinOsc.ar}.play ;
64::
65In this case many server operations are hidden. To understand the  passages involved in the evaluation of this code see link::Tutorials/Getting-Started/04-Functions-and-Other-Functionality:: and link::Tutorials/Getting-Started/10-SynthDefs-and-Synths:: (part of Scott Wilson's tutorial).
66
67The OOP-style also has a small amount of overhead. It requires clientside CPU cycles and memory to create and manipulate an object. Normally this is not significant, but there may be times when you would prefer to use the less elegant, and less expensive first method, for instance when creating large numbers of grains which will simply play and then deallocate themselves.
68
69Thus it is possible to create synth nodes on the server without actually creating Synth objects, providing you are willing to do the required housekeeping yourself. The same is true of group nodes, buffers, and buses. A more detailed discussion of these concepts can be found in the link::Guides/NodeMessaging:: helpfile.
70
71In conclusion, the crucial thing to remember is the distinction between things like nodes, busses, buffers, and servers and the objects that represent them in the language app (i.e. instances of link::Classes/Node::, link::Classes/Bus::, link::Classes/Buffer::, and link::Classes/Server::; these are referred to as 'Server Abstraction Objects'). Keeping these conceptually distinct will help avoid much confusion.
72
73
74section:: Pros/Cons
75
76The client/server architecture provides three main advantages:
77definitionList::
78## stability || if the client crashes, the server keeps on working, i.e. the audio does not stop. This is intuitively relevant for a live situation. Vice versa, the server can crash letting you still manage the situation from the client.
79## modularity || synthesis is one thing, control another. Separating the two aspects allows one to (for example) control the server from applications other than sclang. The only important thing is that they are able to send the right OSC messages to the server.
80## remote control || the client/server network can be external to your computer, e.g. over the Internet. This allows one to control an audio server in Alaska from a client (sclang or other) in India, for example.
81::
82
83There are two notable drawbacks:
84definitionlist::
85## latency || The messaging process introduces a small amount of latency. This should not be confused with audio latency which can be quite low. It only means that there is a small, usually insignificant delay between the one side sending a message and the other receiving it and acting upon it. (This can be minimized by using the 'internal' server. See link::Classes/Server:: for more detail.)
86## asynchronous execution || In some cases the client might need to know that a task on the server (for instance processing a large sound file) has been completed before continuing with another task. Since some tasks take an arbitrary length of time to complete, a reply mechanism is necessary. This can add some complexity to your code, but is in principle not an issue. (See link::Classes/OSCFunc:: and link::Classes/OSCdef::.) Some server abstraction objects such as link::Classes/Buffer:: provide for this automatically through 'action' functions which wait for completion before executing.
87::
88
89section:: A final remark for the advanced reader
90
91Apart from sclang, it is possible to control the server from any other client which provides for OSC messaging (e.g. from Java, Python, Max/MSP, etc.). For networking, see link::Reference/Server-Architecture::, link::Classes/NetAddr::, link::Classes/OSCFunc::.
92
93In general however, sclang is the preferable way to communicate with the server for three reasons:
94list::
95## it gives you the expressive power of the SuperCollider language;
96## the language is explicitly fitted to the server's needs (and, more importantly, to musician's ones)
97## it allows one to create and load SynthDefs onto the server (see link::Classes/SynthDef::), which not all client apps are able to do
98::
99
100