HelpSource/Guides/ClientVsServer.schelp

   1 title:: Client vs Server
   2 summary:: Client versus Server Architecture and Operations
   3 categories:: Server>Architecture, OpenSoundControl
   4
   5 The name "SuperCollider" is in fact used to indicate five different things (Figure 1):
   6 numberedlist::
   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
  14 image::structureEn.png#Figure 1. Structure of the SuperCollider application::
  15
  16 The SuperCollider application is thus made up of two distinct, autonomous, components, a server and a client. The first is named scsynth (SC-synthesizer), the second sclang (SC-language).
  17
  18 section:: Description
  19
  20 The 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
  22 image::s8kfFC-clientServerEn.png#Figure 2. Client/Server architecture::
  23
  24 In 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
  26 To 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 and sclang.
  27
  28 The server app, emphasis::scsynth::, 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
  30 The client of this server is emphasis::sclang::. Sclang performs two distinct tasks:
  31 definitionList::
  32 ## Client || it is the emphasis::client:: for the server, i.e. it sends OSC messages to the server.
  33 In 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
  37 From inside sclang, starting a server app can be accomplished by:
  38 code::
  39 s = Server.default; // create a new Server object and assign it to variable s
  40 s.boot;             // boot the server app, i.e. tell the server to be ready to work
  41 ::
  42 The sclang interpreter can send OSC messages to scsynth in two fashions:
  43 definitionList::
  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.
  45 code::
  46 n = s.nextNodeID;                   // get an available nodeID from the server and assign it to n
  47 s.sendMsg("/s_new", "default", n);  // use the SynthDef "default" to create a synth with ID n
  48 s.sendMsg("/n_free", n);            // release the synth n
  49 ::
  50 ## indirectly || the language app provides you with convienent 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).
  51 code::
  52 x = Synth("default");   // create a synth on the default server (s) and allocate an ID for it
  53 x.free;                 // free the synth, its ID and resources
  54 ::
  55 ::
  56 Working 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 bookeeping greatly reduces the chance of bugs in your own code.
  57
  58 image::scEn.png#Figure 3. Sclang as a high-level client::
  59
  60 Language 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:
  61 code::
  62 // assuming the server is already booted
  63 {SinOsc.ar}.play ;
  64 ::
  65 In this case many server operations are hidden. To understand the  passages inolved in the evalutation of this code see link::Tutorials/Getting-Started/Functions and Other Functionality:: and link::Tutorials/Getting-Started/SynthDefs and Synths:: (part of Scott Wilson's tutorial).
  66
  67 The 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
  69 Thus 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
  71 In 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
  74 section:: Pros/Cons
  75
  76 The client/server architecture provides three main advantages:
  77 definitionList::
  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 scsynth from applications besides 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
  83 There are two notable drawbacks:
  84 definitionlist::
  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/OSCresponder:: and link::Classes/OSCresponderNode::.) Some server abstraction objects such as link::Classes/Buffer:: provide for this automatically through 'action' functions which wait for completion before executing.
  87 ::
  88
  89 section:: A final remark for the advanced reader
  90
  91 Apart from sclang, it is possible to control scsynth 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
  93 In general however, sclang is the preferable way to communicate with scsynth for three reasons:
  94 list::
  95 ## it gives you the expressive power of the SuperCollider language;
  96 ## the language is explicitly fitted to scsynth's needs (and, more importantly, to musician's ones)
  97 ## it allows one to create and load SynthDefs onto scsynth (see link::Classes/SynthDef::), which is a not such an easy task to accomplished in another client app.
  98 ::
  99