This file is indexed.

/usr/share/SuperCollider/HelpSource/Classes/Server.schelp is in supercollider-common 1:3.8.0~repack-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
class:: Server
summary:: Object representing an sc-server application
categories:: Server>Abstractions
related:: Classes/ServerOptions, Reference/Server-Architecture, Reference/Server-Command-Reference

description::

A Server object is the client-side representation of a server app and is used to control the app from the SuperCollider language application. (See link::Guides/ClientVsServer:: for more details on the distinction.)
It forwards OSC messages and has a number of allocators that keep track of IDs for nodes, buses and buffers.

The server application is a commandline program, so all commands apart from OSC messages are unix commands.

The server application represented by a Server object might be running on the same machine as the client (in the same address space as the language application or separately; see below), or it may be running on a remote machine.

Most of a Server's options are controlled through its instance of ServerOptions. See the link::Classes/ServerOptions:: helpfile for more detail.

subsection:: Paths

Server apps running on the local machine have two unix environment variables: code::SC_SYNTHDEF_PATH:: and code::SC_PLUGIN_PATH::. These indicate directories of synthdefs and ugen plugins that will be loaded at startup. These are in addition to the default synthdef/ and plugin/ directories which are hard-coded.

These can be set within SC using the getenv and setenv methods of class link::Classes/String::.
code::
// all defs in this directory will be loaded when a local server boots
"SC_SYNTHDEF_PATH".setenv("~/scwork/".standardizePath);
"echo $SC_SYNTHDEF_PATH".unixCmd;
::

subsection:: The default group

When a Server is booted there is a top level group with an ID of 0 that defines the root of the node tree. (This is represented by a subclass of link::Classes/Group:: : link::Classes/RootNode::.)
If the server app was booted from within SCLang (as opposed to from the command line) the method code::initTree:: will be called automatically after booting.
This will also create a link::Reference/default_group:: with an ID of 1, which is the default group for all link::Classes/Node::s when using object style.
This provides a predictable basic node tree so that methods such as Server-scope, Server-record, etc. can function without running into order of execution problems.

The default group is persistent, i.e. it is recreated after a reboot, pressing cmd-., etc. See link::Classes/RootNode:: and link::Reference/default_group:: for more information.
Note::
If a Server has been booted from the command line you must call code::initTree:: manually in order to initialize the default group, if you want it. See code::initTree:: below.
::

subsection:: Local vs. Internal

In general, when working with a single machine one will probably be using one of two Server objects which are created at startup and stored in the class variables link::#*local:: and link::#*internal::. In SuperCollider.app (OSX), two GUI windows are created to control these. Use link::#-makeGui:: to create a GUI window manually.

The difference between the two is that the local server runs as a separate application with its own address space, and the internal server runs within the same space as the language/client app.

Both local and internal server supports link::#-scope#scoping:: and link::Classes/Bus#Synchronous control bus methods#synchronous bus access::.

The local server, and any other server apps running on your local machine, have the advantage that if the language app crashes, it (and thus possibly your piece) will continue to run. It is thus an inherently more robust arrangement. But note that even if the synths on the server continue to run, any language-side sequencing and control will terminate if the language app crashes.

At the current time, there is generally no benefit in using the internal server, but it remains for the purposes of backwards compatibility.

subsection:: The default Server

There is always a default Server, which is stored in the class variable code::default::. Any link::Classes/Synth::s or link::Classes/Group::s created without a target will be created on the default server. At startup this is set to be the local server (see above), but can be set to be any Server.

subsection:: Local vs. Remote Servers, Multi-client Configurations

Most of the time users work with a server app running on the same machine as the SC language client. It is possible to use a server running on a different machine via a network, providing you know the IP address and port of that server. The link::#*remote:: method provides a convenient way to do this.

One common variant of this approach is multiple clients using the same server. If you wish to do this you will need to set the server's link::Classes/ServerOptions#-maxLogins:: to at least the number of clients you wish to allow.  When a client registers for link::#-notify#notifications:: the server will supply a client ID. This also configures the allocators to avoid conflicts when allocating link::Classes/Node##Nodes::, link::Classes/Buffer##Buffers::, or link::Classes/Bus##Busses::.

In order to use a remote server with tcp one should first boot the remote server using the code::-t:: option and then run the following code:

code::
(
s.options.protocol_(\tcp);
s.addr.connect;
s.startAliveThread( 0 );
s.doWhenBooted({ "remote tcp server started".postln; s.notify; s.initTree });
)
::




ClassMethods::
private:: initClass

method:: new
Create a new Server instance.

argument:: name
a symbol;  each Server object is stored in one global classvariable under its name.

argument:: addr
an optional instance of link::Classes/NetAddr::, providing host and port.
The default is the localhost address using port 57110; the same as the local server.

argument:: options
an optional instance of link::Classes/ServerOptions::. If code::nil::, an instance of ServerOptions will be created, using the default values.

argument:: clientID
an integer. In multi-client situations, every client can be given separate ranges for link::Classes/Node##Nodes::, link::Classes/Buffer##Buffers::, or link::Classes/Bus##Busses::. In normal usage the server will supply an ID automatically when a client registers for link::#-notify#notifications:: so you should not need to supply one here. N.B. In multi-client situations you will need to set the link::Classes/ServerOptions#-maxLogins:: to at least the number of clients you wish to allow. This must be the same in the Server instances on every client.

method:: remote
Create a new Server instance corresponding to a server app running on a separate machine. This method assumes the remote app has been booted, and starts listening immediately. You should not call link::#-boot:: on an instance created using this method.

argument:: name
a symbol;  each Server object is stored in one global classvariable under its name.

argument:: addr
an optional instance of link::Classes/NetAddr::, providing ip address of the remote machine and port the app is listening on.

argument:: options
an optional instance of link::Classes/ServerOptions::. If code::nil::, an instance of ServerOptions will be created, using the default values.

argument:: clientID
an integer. In multi-client situations, every client can be given separate ranges for link::Classes/Node##Nodes::, link::Classes/Buffer##Buffers::, or link::Classes/Bus##Busses::. In normal usage the server will supply an ID automatically when a client registers for link::#-notify#notifications:: so you should not need to supply one here. N.B. In multi-client situations you will need to set the link::Classes/ServerOptions#-maxLogins:: to at least the number of clients you wish to allow. This must be the same in the Server instances on every client.


method:: local
get/set the local server, stored in classvar code::local:: (created already on initClass)

method:: internal
get/set the internal server, stored in classvar code::internal:: (created already on initClass)

method:: default
Get or set the default server. By default this is the local server (see above).
discussion::
Setting this will also assign it to the link::Classes/Interpreter:: variable 's'.
code::
Server.default = Server.internal; // set the internal Server to be the default Server
s.postln; // internal
::

method:: all
get/set the set of all servers.

method:: allRunningServers
returns:: the set of all running servers.

method:: quitAll
quit all registered servers

method:: killAll
query the system for any sc-server apps and hard quit them

method:: freeAll
free all nodes in all registered servers

method:: supernova

Switches the server program to supernova. Check link::Classes/ParGroup:: how to make use of multicore hardware with the supernova server.

method:: scsynth

Switches the server program to scsynth. This is the default server.


InstanceMethods::

private:: doSend

method:: sendMsg
send an OSC-message to the server.
discussion::
code::
s.sendMsg("/s_new", "default", s.nextNodeID, 0, 1);
::

method:: sendBundle
send an OSC-bundle to the server.
discussion::
Since the network may have irregular performance, time allows for the bundle to be evaluated at a specified point in the future.
Thus all messages are synchronous relative to each other, but delayed by a constant offset.
If such a bundle arrives late, the server replies with a late message but still evaluates it.
code::
s.sendBundle(0.2, ["/s_new", "default", x = s.nextNodeID, 0, 1], ["/n_set", x, "freq", 500]);
::

method:: sendRaw

method:: listSendMsg
as sendMsg, but takes an array as argument.

method:: listSendBundle
as sendBundle, but takes an array as argument.
discussion::
This allows you to collect messages in an array and then send them.
code::
s.listSendBundle(0.2, [["/s_new", "default", x = s.nextNodeID, 0, 1],
    ["/n_set", x, "freq", 600]]);
::

method:: sendSynthDef
send a synthDef to the server that was written in a local directory

method:: loadSynthDef
load a synthDef that resides in the remote directory

method:: loadDirectory
load all the SynthDefs in the directory dir.
argument:: dir
a link::Classes/String:: which is a valid path.
argument:: completionMsg

method:: nextNodeID
get a unique nodeID.

method:: nextPermNodeID
get a permanent node ID. This node ID is in a reserved range and will be held until you explicitly free it.

method:: freePermNodeID
free a permanent node ID for later reuse.

method:: wait
this can be used within a link::Classes/Routine:: to wait for a server reply

method:: waitForBoot
Evaluate "onComplete" as soon as the server has booted. This method will boot the server for you if it is not already running or booting. If the server is already running, "onComplete" is executed immediately.
argument:: onComplete
A function to evaluate after the server has booted successfully.
argument:: limit
The number of times to check for a successful boot. (5 times/sec)
argument:: onFailure
A function to evaluate after the server fails to boot. If onFailure is not given, an error message is posted. Providing a function suppresses the error message. If you want to supply a function and print the normal error message, make sure that your function returns "false," e.g. code::s.waitForBoot(onFailure: { ... custom action...; false })::.

method:: doWhenBooted
Evaluate "onComplete" as soon as the server has booted. This method assumes the server is being booted explicitly through a separate code::boot:: call. If the server is already running, "onComplete" is executed immediately.
argument:: onComplete
A function to evaluate after the server has booted successfully.
argument:: limit
The number of times to check for a successful boot.
argument:: onFailure
A function to evaluate after the server fails to boot. If onFailure is not given, an error message is posted. Providing a function suppresses the error message. If you want to supply a function and print the normal error message, make sure that your function returns "false," e.g. code::s.doWhenBooted(onFailure: { ... custom action...; false })::.

method:: boot
boot the remote server, create new allocators.
argument:: startAliveThread
If true, start a Routine to send a /status message to the server every so often. The interval between the messages is set by code::theServer.aliveThreadPeriod = (seconds)::. The default period is 0.7. If false, /status will not be sent and the server's window will not update.
argument:: recover
If true, create a new node ID allocator for the server, but use the old buffer and bus allocators. This is useful if the server process did not actually stop. In normal use, the default value "false" should be used.
argument:: onFailure
In this method, the onFailure argument is for internal use only. If you wish to take specific actions when the server boots or fails to boot, it is recommended to use link::#-waitForBoot:: or link::#-doWhenBooted::.
discussion::
N.B. You cannot boot a server app on a remote machine.

method:: quit
quit the server application

method:: reboot
quit and restart the server application

method:: freeAll
free all nodes in this server

method:: status
query the server status

method:: notify
The server sends notifications, for example if a node was created, a 'tr' message from a link::Classes/SendTrig::, or a strong::/done:: action. if code::flag:: is set to false, these messages will not be sent to this client. The default is true. If true the server will respond with a clientID (scsynth only) which can be useful in multi-client situations. If this is different from any previously received ID new allocators will be created. See link::#Local vs. Remote Servers, Multi-client Configurations:: for more information.

method:: ping
measure the time between server and client, which may vary. the code::func:: is
evaluated after code::n:: number of times and is passed the resulting maximum.

method:: options
Get or set this Server's link::Classes/ServerOptions:: object. Changes to options only take effect when the server is rebooted.

method:: defaultGroup
returns:: this Server's default group.

method:: volume
Get an instance of Volume that runs after the default group, or sets the Volume of the Server's output to level. Level is in db.

method:: mute
mute the server's output. This can also be toggled from the Server window with the 'm' key.

method:: unmute
unmute the server. This can also be toggled from the Server window with the 'm' key.

method:: reorder
Move the nodes in code::nodeList:: to the location specified by code::target:: and code::addAction::, placing them there in the order indicated by nodeList.
discussion::
Any nodes which have already been freed will be skipped. Passing nil for target and addAction will result in the location being the head of the default group.
code::
g = Group.new;
x = Array.fill(5, {Synth(\default)});
s.queryAllNodes;
s.reorder(x, g, \addToTail);
s.queryAllNodes;
::

method:: inputBus
Return a link::Classes/Bus:: object that represents the input audio bus.

method:: outputBus
Return a link::Classes/Bus:: object that represents the output audio bus.


subsection:: Information and debugging

method:: dumpOSC
argument:: code
table::
## 0 || turn dumping OFF.
## 1 || print the parsed contents of the message.
## 2 || print the contents in hexadecimal.
## 3 || print both the parsed and hexadecimal representations of the contents.
::

note:: teletype::/status:: messages won't be posted, when dumping is enabled::

method:: queryAllNodes
Post a representation of this Server's current node tree to the post window. See link::#-plotTree:: for a graphical variant.
discussion::
Very helpful for debugging. For local servers this uses g_dumpTree and for remote g_queryTree. See link::Classes/Group:: and link::Reference/Server-Command-Reference:: for more info.
code::
s.boot;
s.queryAllNodes; // note the root node (ID 0) and the default group (ID 1)
s.quit;
::

method:: peakCPU, avgCPU
Get peak and average CPU usage.

method:: numSynths
Get number of running link::Classes/Synth::s.

method:: numGroups
Get number of link::Classes/Group::s.

method:: numUGens
Get number of running link::Classes/UGen::s.

method:: numSynthDefs
Get number of loaded link::Classes/SynthDef::initions.

method:: pid
Get process ID of running server (if not internal).

method:: hasShmInterface
Returns true if a link::Classes/ServerShmInterface:: is available. See also link::Classes/Bus#Synchronous control bus methods::.
discussion::
The shared memory interface is initialized after first server boot.

subsection:: Automatic Message Bundling

Server provides support for automatically bundling messages. This is quite convenient in object style, and ensures synchronous execution. See also link::Guides/Bundled-Messages::

method:: makeBundle
The Function code::func:: is evaluated, and all OSC messages generated by it are deferred and added to a bundle.
argument:: time
If set to nil or a number the bundle will be automatically sent and executed after the corresponding delay in seconds. If code::time:: is set to false the bundle will not be sent.
argument:: func
The function to evaluate.
argument:: bundle
allows you to pass in a preexisting bundle and continue adding to it.
returns:: The bundle so that it can be further used if needed.
discussion::
Calling code::sync:: inside func will split the bundle and wait for asynchronous actions to complete before continuing.

If an error is encountered while evaluating code::func:: this method will throw an link::Classes/Error:: and stop message deferral.
code::
s.boot;
(
// send a synth def to server
SynthDef("tpulse", { arg out=0,freq=700,sawFreq=440.0;
	Out.ar(out, SyncSaw.ar(freq,  sawFreq,0.1) )
}).add;
)

// all OSC-commands generated in the function contained below will be added to a bundle
// and executed simultaneously after 2 seconds.
(
s.makeBundle(2.0, {
	x = Synth.new("tpulse");
	a = Bus.control.set(440);
	x.map(\freq, a);
});
)
x.free;

// don't send
(
b = s.makeBundle(false, {
	x = { PinkNoise.ar(0.1) * In.kr(0, 1); }.play;
});
)
// now pass b as a pre-existing bundle, and start both synths synchronously
(
s.makeBundle(nil, { // nil executes ASAP
	y = { SinOsc.kr(0.2).abs }.play(x, 0, 0, \addBefore); // sine envelope
}, b);
)
x.free; y.free;

// Throw an Error
(
try {
	s.makeBundle(nil, {
		s.farkermartin;
	});
} { |error|
	("Look Ma, normal operations resume even though:\n" + error.errorString).postln;
	x = { FSinOsc.ar(440, 0, 0.2) }.play; // This works fine
}
)
x.free;

// use sync
(
s.makeBundle(nil, {
	b = Buffer.read(s, Platform.resourceDir +/+ "sounds/a11wlk01.wav");
	s.sync; // wait until load is done and then send the rest of the bundle
	x = { PlayBuf.ar(1, b) * 0.5 }.play;
});
)
x.free; b.free;
::

method:: bind
Just as in code::makeBundle::, the Function code::func:: is evaluated, and all OSC messages generated by it are deferred and added to a bundle, which is sent to the server, using the server default latency.
discussion::
code::
(
s.bind {
	a = { |freq=100| SinOsc.ar(freq, LFTri.ar(freq)) * 0.2 }.play;
    s.sync;
	a.set(\freq, 400);
}
)
::

subsection:: Shared Controls

The internal server has a number of shared control buses. Their values can be set or polled using the methods below.

method:: getSharedControl
get the current value of a shared control bus. num is the index of the bus to poll. This command is synchronous and only works with the internal server.

method:: setSharedControl
set the current value of a shared control bus to value. num is the index of the bus to set. This command is synchronous and only works with the internal server.

method:: allocSharedControls
set the number of shared control buses. Must be done before the internal server is booted. The default is 1024.

subsection:: Persistent Node Trees

The class link::Classes/ServerTree:: can be used to store functions which will be evaluated after the server is booted, after all nodes are freed, and after cmd-. is pressed.
This allows, for example, for one to create a persistent basic node structure. ServerTree is evaluated in the method initTree after the default group is created, so its existence can be relied upon.

method:: initTree
This method initializes the link::Reference/default_group:: and runs link::Classes/ServerTree::.
discussion::
This method is called automatically when you boot a Server from the language. N.B. If you started a server app from the command line you will have to call initTree manually if you need this functionality.
code::
s.quit;
f = {Group.new(s.defaultGroup); "Other code can be evaluated too".postln;};
ServerTree.add(f);
s.boot;
s.queryAllNodes; // note the group within the default group
ServerTree.remove(f);
::
link::Classes/ServerBoot:: and link::Classes/ServerQuit:: provide similar functionality at boot and quit times.

subsection:: GUI methods

method:: makeGui
Create and show the server window. The window responds to a number of keyboard shortcuts:
table::
## strong::key:: || strong::action::
## teletype::n:: || Post a representation of this Server's current node tree to the post window. (See link::#-queryAllNodes::)
## teletype::N:: || As 'n' above but include controls.
## teletype::l:: || Show input/output level meters. (See link::#-meter::)
## teletype::p:: || Show graphical view of the node tree. (See link::#-plotTree::)
## (space) || Boot server if not already booted. (See link::#-boot::)
## teletype::s:: || Show scope window. (See link::#-scope::)
## teletype::f:: || Show frequency analyzer window. (See link::#-freqscope::)
## teletype::d:: || Toggle dumping of OSC messages.
## teletype::m:: || Toggle mute.
## teletype::0:: || Reset volume to 0 db.
::


method:: scope
Open a scope window showing the output of the Server.
see link::Classes/Stethoscope:: for further details.

argument:: numChannels
the number of channels to be scoped out. The default is this server's options' numOutputBusChannels.
argument:: index
the first channel to be output. The default is 0.
argument:: bufsize
the size of the buffer for the ScopeView. The default is 4096.
argument:: zoom
a zoom value for the scope's X axis. Larger values show more. The default is 1.
argument:: rate
whether to display audio or control rate buses (either \audio or \control)

method:: freqscope
Show frequency analyzer window.

method:: meter
Show input/output level meters.

method:: plotTree
Plot the node/group tree. As link::#-queryAllNodes:: but graphical.

argument:: interval
Polling interval.

method:: plotTreeView
Plot the node/group tree graphically on a given view.

argument:: interval
Polling interval.

argument:: parent
Parent view.

argument:: actionIfFail
Function to be evaluated in case communication with the server cannot be established.

returns:: Function to be evaluated in order to clean up all actions performed inside the method. To be called for instance by the onClose method of the enclosing window.

subsection:: Recording Support

The following methods are for convenience use. For recording with sample accurate start and stop times you should make your own nodes. See the link::Classes/DiskOut:: helpfile for more info. For non-realtime recording, see the link::Guides/Non-Realtime-Synthesis:: helpfile.

This functionality is also available through the recording button on the server windows.
Pressing it once calls record, and pressing it again calls stopRecording (see below). When doing so the file created will be in your recordings folder and be named for the current date and time.
The default location of the recordings folder varies from platform to platform but is always stored in code::thisProcess.platform.recordingsDir::. Setting this variable allows you to change the default.

NOTE::
record creates the recording synth after the Server's default group and uses In.ar. Thus if you add nodes after the recording synth their output will not be captured.
To avoid this, either use Node objects (which use the default node as their target) or (when using messaging style) use a target nodeID of 1.
code::
s.sendMsg("/s_new", "default", s.nextNodeID, 1,1);
::
::

For more detail on this subject see link::Guides/Order-of-execution::, link::Reference/default_group::, and link::Guides/NodeMessaging::.

See link::Classes/SoundFile:: for information on the various sample and header formats.
Not all sample and header formats are compatible. Note that the sampling rate of the output file will be the same as that of the server app. This can be set using the Server's link::Classes/ServerOptions::.

Example:
code::
s.boot; // start the server

// something to record
(
SynthDef("bubbles", {
	var f, zout;
	f = LFSaw.kr(0.4, 0, 24, LFSaw.kr([8,7.23], 0, 3, 80)).midicps; // glissando function
	zout = CombN.ar(SinOsc.ar(f, 0, 0.04), 0.2, 0.2, 4); // echoing sine wave
	Out.ar(0, zout);
}).add;
)

x = Synth.new("bubbles");

s.prepareForRecord; // if you want to start recording on a precise moment in time, you have to call this first.

s.record;

s.pauseRecording; // pausable

s.record // start again

s.stopRecording; // this closes the file and deallocates the buffer recording node, etc.

x.free; // stop the synths

// look in your recordings folder and you'll find a file named for this date and time
::

method:: prepareForRecord
Allocates the necessary buffer, etc. for recording the server's output. (See code::record:: below.)
argument:: path
a link::Classes/String:: representing the path and name of the output file.
discussion::
If you do not specify a path than a file will be created in your recordings folder (see the note above on this) called SC_thisDateAndTime. Changes to the header or sample format, or to the number of channels must be made strong::before:: calling this.

method:: record
Starts or resumes recording the output.
argument:: path
this is optional, and is passed to code::prepareForRecord:: (above).
discussion::
If you have not called prepareForRecord first (see above) then it will be invoked for you (but that adds a slight delay before recording starts for real).

method:: pauseRecording
Pauses recording. Can be resumed by executing record again.

method:: stopRecording
Stops recording, closes the file, and frees the associated resources.
discussion::
You must call this when finished recording or the output file will be unusable. Cmd-. while recording has the same effect.

method:: recordNode
Returns:: the current recording synth so that it can be used as a target. This should only be necessary for nodes which are not created in the default group.

method:: recChannels
Get/set the number of channels (int) to record. Is automatically set to the value of link::Classes/ServerOptions#-numOutputBusChannels:: when booting the server. Must be called strong::before:: prepareForRecord.

method:: recHeaderFormat
Get/set the header format (string) of the output file. The default is "aiff". Must be called strong::before:: prepareForRecord.

method:: recSampleFormat
Get/set the sample format (string) of the output file. The default is "float". Must be called strong::before:: prepareForRecord.

method::recBufSize
Get/set the size of the link::Classes/Buffer:: to use with the link::Classes/DiskOut:: UGen. This must be a power of two. The default is the code::sampleRate.nextPowerOfTwo:: or the first power of two number of samples longer than one second. Must be called strong::before:: prepareForRecord.

subsection:: Asynchronous Commands

Server provides support for waiting on the completion of asynchronous OSC-commands such as reading or writing soundfiles. N.B. The following methods must be called from within a running link::Classes/Routine::. Explicitly passing in a link::Classes/Condition:: allows multiple elements to depend on different conditions. The examples below should make clear how all this works.

method:: bootSync
Boot the Server and wait until it has completed before resuming the thread.
argument:: condition
an optional instance of link::Classes/Condition:: used for evaluating this.

method:: sendMsgSync
Send the following message to the wait until it has completed before resuming the thread.
argument:: condition
an optional instance of link::Classes/Condition:: used for evaluating this.
argument:: ... args
one or more valid OSC messages.

method:: sync
Send a code::/sync:: message to the server, which will replie with the message code::/synced:: when all pending asynchronous commands have been completed.
argument:: condition
an optional instance of link::Classes/Condition:: used for evaluating this.
argument:: bundles
one or more OSC messages which will be bundled before the sync message (thus ensuring that they will arrive before the /sync message). argument:: latency
allows for the message to be evaluated at a specific point in the future.

discussion::
This may be slightly less safe then sendMsgSync under UDP on a wide area network, as packets may arrive out of order, but on a local network should be okay. Under TCP this should always be safe.
code::
(
Routine.run {
	var c;

	// create a condition variable to control execution of the Routine
	c = Condition.new;

	s.bootSync(c);
	\BOOTED.postln;

	s.sendMsgSync(c, "/b_alloc", 0, 44100, 2);
	s.sendMsgSync(c, "/b_alloc", 1, 44100, 2);
	s.sendMsgSync(c, "/b_alloc", 2, 44100, 2);
	\b_alloc_DONE.postln;
};
)

(
Routine.run {
	var c;

	// create a condition variable to control execution of the Routine
	c = Condition.new;

	s.bootSync(c);
	\BOOTED.postln;

	s.sendMsg("/b_alloc", 0, 44100, 2);
	s.sendMsg("/b_alloc", 1, 44100, 2);
	s.sendMsg("/b_alloc", 2, 44100, 2);
	s.sync(c);
	\b_alloc_DONE.postln;
};
)
::