SuperCollider 3 Server on Linux ● History ● Architecture ● Server ● Language ● SCEL ● SCUM ● Further Development ● Resources
History ● James McCartney developed SuperCollider on Mac OS 9 and OS X: – Synth-O-Matic (1990) – pyrite : MAX object – SuperCollider version 1 (1996), version 2 (1998), version 3d5 (2000) – SuperCollider 3 Server (2002) ● Linux : – alpha port of the server (2002) – alpha port of the language (2003) – first fully functional version in November 2003 ● Windows port of the server by Ross Bencina
Architecture ● Client-Server-Model ● Server application ( scsynth ) provides sound synthesis facilities ● Client application ( sclang ) provides high-level abstractions for communicating with scsynth ● Asynchronous communication via TCP/UDP and OpenSoundControl ( OSC ) messages ● Client/Server may reside on the same machine or on different hosts in a LAN
OpenSoundControl (1) ● Protocol for inter-application communication ● Developed at CNMAT /Berkeley ● Transport-independent ● Hierarchical, extensible address space ● Packet-based, stateless ● Packet types – Bundle : contains timestamp, messages and other bundles – Message : carries actual information ● Data types: int32 , float32 , string , blob (untyped binary data)
OpenSoundControl (2) ● Anatomy of an OSC message: '/oscil/1/freq' 'f' 444.1 padded type string padded address string 32 bit float (network byte order)
Server (Overview) ● Performs DSP computations and manages resources (synths, buses, buffers, etc.) ● Core features: – small, efficient, portable – embeddable by linking to libscsynth – complete OSC command set – client application independent – JACK driver backend on Linux
Synthesis Tree ● Synthesis modules are part of a tree that defines order of execution ● Nodes are referenced by an integer identifier ● Node types – Group : Container for nodes (linked list) – Synth : synthesis graph of unit generators ( Ugen s) ● Vertices define containment relationship
Nodes ● Group s contain groups and synths ● Top level group with id 0 ● Nodes in a Group can be controlled simultanously ● Synth s are a collection of UGens ● Created from synth definitions ● Connected through global control and audio buses ● Local buses allow modular realization of recursive synthesis techniques
UGens, Synth Definitions ● UGen definitions are loaded from plugins – Currently SuperCollider includes about 300 UGens for building synthesis graphs – UGen types (incomplete): ● I/O to and from buses, files ● Delays ● Oscillators ● Low frequency control ● Filters ● Frequency domain processing ● Triggers ● SynthDef s are named templates for creation of synths – Binary file format
Buses, Buffers ● Buses are global arrays of scalar control and audio values for synth interconnections ● Indexed by integers beginning at 0 ● Lowest numbered audio buses are read from and written to by the audio hardware ● Buffers are tables of floating point values ● Manipulation even while synthesis is running: – allocate, free – read from or write to a soundfile – fill using variety of functions ● Used for wavetables, sample buffers, delay lines, FFT buffers, etc.
Synthesis Tree Top 0 FX 2 Instruments 1 Reverb 1003 Synth 1002 Synth 1001 Mixer 1004 Mix Buses DAC Output Buses
Language (Overview) ● Object oriented language with many features applicable to composition and performance ● Incorporates ideas from Smalltalk, Ruby, APL, ... ● Core features: – Virtual machine model with byte compilation – Constant time method lookup – Realtime garbage collector – Dynamically typed – Closures – Routines (restartable functions, “coroutines”) – ALSA sequencer support on Linux
Object Model ● Object model similar to Smalltalk's: – single inheritance – root class Object – method invocation by sending messages ● Notable differences: – class definitions cannot be added at runtime – global method lookup matrix, similar to C++ vtables – syntax closer to C than Smalltalk Routine({ #["Hello", "SuperCollider", "world!"].do({ |s| s.postln; rrand(0.5, 2).wait; }); }).play;
SynthDefs ● SynthDefs (synthesis graph definitions) are created by evaluating UGen graph functions ● UGen graphs are optimized and compiled into a binary representation ● The compiled SynthDef is loaded into the server while it is running SynthDef("whirl", { | out = 0, gate, panfreq | var freq, env, zout; freq = LFSaw.kr(0.3, 0, 24, LFSaw.kr([8, 7.23], 0, 4, 80)).midicps; env = EnvGen.ar( Env.asr(1.0, 1.0, 2.0), gate, levelScale: 0.04, doneAction: 2 ); zout = CombN.ar(SinOsc.ar(freq, 0, env), 0.2, 0.2, 4); Out.ar(out, Mix(Pan2.ar(zout, SinOsc.kr(panfreq)))); }).send(Server.default);
Proxy Objects ● Proxy Objects are a means of creating nodes on the server and controlling them through objects in the language proper ● Implicit or explicit resource ID management ● Proxy classes for – Groups – Synths – Buses – Buffers x = Synth(“whirl”, [\gate, 1, \panfreq, 1]); x.set(\panfreq, 0.3); x.release;
Streams ● Streams represent finite or infinite sequences of values (lazy evaluation) ● Important messages: – next – reset ● Routines are functions that can return a value and be resumed from that point ● Streams create a new Stream when sent a – binary message, e.g. + – iteration message, e.g. select ● By default any object represents an infinite sequence of itself
Patterns ● Patterns are template specifications for creating Streams ● Streams are created from Patterns by sending the asStream message ● Patterns can be nested ● Common Patterns: – Pfunc , Prout : Functions and Routines – Pseq : sequence – Prand , Pshuf : random selection – Pn : looping – Pcollect , Pselect , Preject : filters
Events ● Event s are a collection of parameters, mapping symbols to values ● Hierarchical parameter models for pitch and amplitude ● EventPlayer s realize an Event, e.g. by – creating a Synth with initial parameters – setting parameters of a running Node ● Pbind binds symbols in each Event to values obtained from patterns ● EventStreamPlayer s are created by sending a pattern the asEventStreamPlayer message ● EventStreamPlayers can be started, stopped, paused and resumed
Scheduling ● Clock s evaluate functions in a timed fashion ● Return value is interval to next invocation ● Schedulable objects include: – Functions, Routines, Streams – Patterns (EventStreamPlayers) ● SystemClock – singleton class – time base: seconds ● TempoClock – each instance runs in a high-priority thread – instances maintain their temporal relationship accurately over a long period – time base: beats, tempo: beats/second
Add-On Libraries ● Additional libraries extend SuperCollider's core functionality, e.g. – JITLib : proxy spaces, live coding – BBCut : algorithmic break beat cutting
SCEL ● SCEL ( S uper C ollider E macs L isp) is a comprehensive IDE for working with SuperCollider on Linux ● sclang-mode – syntax colorization – automatic indentation – autocompletion for symbol names and method arguments ● Interpreter interface – code evaluation – class and method definition browsing – RTF help file access – Document manipulation from SuperCollider code
SCUM (Overview) ● SCUM ( refuse; recrement; anything vile or worthless ), GUI classes for SuperCollider ● Core features: – lightweight – portable – flexible layout management – OpenGL integration ● Currently runs on Linux using FLTK for – drawing – event handling – window management – OpenGL contexts
SCUM Examples ● Server Panel ● Simple sequencer
Further Development ● Completion of GUI classes on Linux – Multislider – Envelope editor – Plot view ● Visualization facilities: – Integration of Christophe Costigan's OpenGL bindings – Canvas view ● Integration of HID event sources
Resources ● James McCartney's homepage – http://www.audiosynth.com ● Sourcefourge page – http://supercollider.sourceforge.net ● Linux page on the Swiki – http://swiki.hfbk-hamburg.de:8888/MusicTechnology/478 ● Mailing lists – http://www.create.ucsb.edu/mailman/listinfo/sc-users – http://www.create.ucsb.edu/mailman/listinfo/sc-dev ● SCUM sources – http://www.cs.tu-berlin.de/~kerstens/pub
Recommend
More recommend