hello there,

building on andreas schlegel's excellent oscP5 library, i've created a series of objects to easily interface processing with supercollider. they're directly analogous to those in supercollider's client-side language: Server, Synth, Bus, Buffer, etc. using this interface, it's trivial to create and manipulate complex synthesis graphs.

an early release version of the library can be downloaded (with source) at:
http://www.erase.net/projects/p5_sc/

more examples coming soon. it's also currently lacking some functions that are available in sc's own client language, notably asynchronous commands and those which perform an action upon completion (synth.get(), for example).

this is the first library that i've released to the public, so please do let me know if you experience any problems.

i've used this code for several live performances, so much of it should be reasonably stable. below is an applied example of the library; the visuals are generated purely by processing, and the sound by supercollider.
http://uk.youtube.com/watch?v=_IPeO-VnFBs

have fun!

daniel

my pleasure - i was quite surprised to find that nobody had already released an sc library, as it's a stunningly effective partnership.

i've now introduced support for asynchronous commands such as Buffer.read, which invoke a callback upon their completion. example code is available in the Buffer documentation:

http://www.erase.net/projects/p5_sc/reference/buffer

julio,

i've mostly focused on implementing the objects relating to the core server commands, to enable processing to interact with the server in as many ways as the native sc client can.

what other elements are you referring to the ones that have struck me as potentially useful and viable are streams/patterns and some of supercollider's scheduling structures. however, both of these are arguably outside the scope of this library.

perhaps more useful and relevant would be the ability to create synthdefs from processing, but this is sadly not really feasible.

did you have specific tasks/components in mind

my work is mostly based around triggering synth objects from dynamical systems and other events within the processing environment, which i guess is quite a separate paradigm to the linear sequencing of streams and patterns - but both are equally valid and would be useful sets of classes. i'll give some thought to developing some structures along the lines of patterns.

as the p5_sc library using bundle timestamps for accurate event scheduling, it should be possible to do sufficiently fine-grained operations such as the client-side granulation you mention. i'm not sure what the best way would be of handling these tasks alongside processing's native frame timing..

let me know if you run into any issues, as i'd be glad to help.

dan

Hi Dan,

Thank you very much for making this available. It saves me a lot of time!

I tried the tutorial that reads a sound file, but I couldn't get SuperCollider to play it (http://www.erase.net/projects/p5_sc/examples/buffer_read), while the tutorial "Buffer.fill" worked fine.

I changed the code of the SynthDef so that it would print something when it's called (see below), but it doesn't print anything in the SC console.

I suppose the function create() calls the function SynthDef.new() ? When it's called in Processing, it should play the sound, isn't it? This is where it does not work for me.

I've listen to the port 57110 using dumpOSC and this is what is sent from Processing:

/b_allocRead 0 "/Users/jbt/sounds/mysound.AIF" 0 0 [Unrecognized type tag b]

Would you have any idea, I'd really appreciate your help.

Best,
JB

--
Code:

SC code

SynthDef(\playbuf_2, { |bufnum = 0, outbus = 0, amp = 0.5, loop = 0, rate = 1.0|

var data;

data = PlayBuf.ar(2, bufnum, BufRateScale.kr(bufnum) * rate, 0, 0, loop);

FreeSelfWhenDone.kr(data);

Out.ar(outbus, data * amp); postln("toto");
}).store;
 

dan wrote on Dec 19^th, 2007, 12:51pm:

I just tried running this example on Processing 1.0, OSX10.5.5

import oscP5.*;

import supercollider.*;

Synth synth;

void setup ()
{
   size(800, 200);

   // uses default sc server at 127.0.0.1:57110    
   // does NOT create synth!
   synth = new Synth("sine");
   
   // set initial arguments
   synth.set("amp", 0.5);
   synth.set("freq", 80);
   
   // create synth
   synth.create();
}

void draw ()
{
   background(0);
   stroke(255);
   line(mouseX, 0, pmouseX, height);
}

void mouseMoved ()
{
   synth.set("freq", 40 + (mouseX * 3));
}

void stop ()
{
   synth.free();
}

I get the following output:



### [2008/11/29 14:37:50] PROCESS @ OscP5 stopped.
### [2008/11/29 14:37:50] PROCESS @ UdpClient.openSocket udp socket initialized.
### [2008/11/29 14:37:51] PROCESS @ UdpServer.start() new Unicast DatagramSocket created @ port 57150
### [2008/11/29 14:37:51] PROCESS @ UdpServer.run() UdpServer is running @ 57150
### [2008/11/29 14:37:51] INFO @ OscP5 is running. you (192.168.1.115) are listening @ port 57150


I have SC 3.2 (Revision 7362) installed and can run basic stuff on that, so I'm thinking the problem isn't with SC itself. Any thoughts/suggestions? Thanks,

Sorry, completely forgot to mention the problem (too many things going while I was writing the post). There's no sound. From reading the documentation there doesn't seem to be anything else that I need to do to get the synth playing, am I missing something in there?

Ok, cool. That works, but I had hoped there would be a way to actually create the synth in the Processing code and not have to write any code on the SC side. Is that not the intended functionality?