v 0.996 -- January 2011
based on SuperCollider 3, v 3.4
Mac OSX 10.5/6; Max5
[sc3~] links the sound synthesis and signal-processing capabilities
music programming language into the
real-time music environment.
This extends both applications in a variety of ways:
[sc3~] is similar in many of these respects to the
- [sc3~] integrates the full range of SC3 synthesis and
signal-processing capabilities into the Max/MSP graphical patching
- Within Max/MSP, the [sc3~] object can easily link to other
development languages and environments, including Jitter (OpenGL),
- SuperCollider 3 scripts can be developed, triggered and controlled
from within Max/MSP, and the
scripts can be saved with Max/MSP patchers for easy storage and retrieval.
The original SuperCollider language was written by James McCartney and is
now an open source (GPL) project maintained and developed by various
For more information about the SuperCollider 3 language,
Download and Install
(sorry, no windows version at present!)
Earlier versions of the [sc3~] object for older Max and
OSX machines are available
SuperCollider 3 is covered by the
GNU General Public License (GPL).
The following downloadable archive contains the source code and XCode
project for the [sc3~] object, the sclangpipe command
used to bridge between the proprietary Max/MSP application and SuperCollider
3 application, and the files modified to allow the scsynth
process to send audio through a UDP socket:
(66 Kbytes download/320 Kbytes on disk)
sc3~ 0.996 using SC3 v 3.4 -- 1/31/2011
Note the less-than 1.0 designation of this object. I'm sure it
is probably a bit "brittle", it has not been extensively tested
and the method I use to invoke the SC3 processes can sometimes
be very flaky. I hope people can find some use from the object.
If enough interest is there, I may work to fix outstanding bugs and
make it more robust. I'm also not a terrific SuperCollider programmer
(as you will see by looking through some of my SC3 code in the
help patcher), so there is much that I've 'left to the imagination'.
Such is life.
I do know to watch out for these particular issues:
1. The scsynth server process takes about 5-10 seconds to
initialize even after the "SC3 server started" message appears in
the Max window. If you send any SC3 scripts prior to this initialization,
nothing will happen. This becomes problematic when SynthDefs or other
initialization code need to be sent. Keep clicking, and be (ever-so-slightly)
I'll bet there are many more problems with the
[sc3~] object, but they probably won't show up until just
after I make this all publicly-accessible. Let me know how it
goes for you!
2. Issue #1 could be resolved by having the [sc3~] object send
a bang out through an outlet once it receives notification that the
server is initialized. Unfortunately data coming back from the
server through the sclang process is not retrievable in this
version of the object.
3. This also means that you will not see output from SC3 in the
Max window. All SC3 language and server printing goes to the
system console window, to view it use /Applications/Utilities/Console.app.
OSX does a really ridiculous buffering of this window (can anyone
tell me how to circumvent it?), so it may take awhile for the
SC3 messages to appear.
4. Very occasionally I have noticed that one of the UDP ports used by
[sc3~] won't close 'cleanly', and this prevents the object
from working properly. The port will eventually be released.
This seems to happen when working with [sc3~] objects
nested in sub and sub-sub patchers, especially if you are deleting
and creating new ones. You can 'fix' the situation by
creating a new [sc3~] object and using it in place
of the one causing the problem. Or reboot your machine.
5. You will note on the help patcher a comment that [sc3~]
works best when the signal-vector and i/o-vector sizes are both
equal in Max/MSP. This has to do with the way audio buffers are
being filled and sent from scsynth. Other combinations of
signal and i/o vectors will work, but the CPU load gets very
intense. Also, when the i/o vector is more than 4 times larger
than the signal vector you may hear 'skipping' or interrupts in the
sound. Vector sizes smaller than 32 are also difficult. 256/256,
512/512, and 1024/1024 all seem to work very well.
5a. Something has changed in OSX 10.6 which causes problems
with multiple servers. It seems that a large (4096 or greater)
vector size is needed to prevent buffer gaps/clicks when using more
than one server in a patcher. I'm not sure why this is. Sorry!
6. Stereo only for now. I also haven't tested this much with
external audio hardware, but it should work ok...
7. Certain quarks interfere with [sc3~] operation. I believe
they are quarks with a graphic component, which makes sense. Check the
max/msp forum archives for discussion of these.
[NOTE: Any bad-coding problems in the [sc3~] object
'proper' are all mine mine mine, of course. I'm not a Real Programmer.]
garton - at - columbia dot edu