SuperCollider On Organelle


This is fantastic! I had given up on this. Thanks @thetechnobear! Can’t wait to try it on my Organelle. :slight_smile:


i had not read through it all it looked like you were close to releasing it so just give a holler when you have it where you like and i’ll pull some examples for testing




Ok, an initial release is now available, including a test patch

SC_Install has been updated, and is required to be reinstalled
You will need to install TB17 to launch supercollider patches

mother.scd should be considered ‘experimental’, i.e. it will be changing/updated, the current release is to allow myself and others to get some experiences of what might need to be changed etc.
so dont start building huge patches based on it… or if you do, be prepared to have to update them :wink:

Install instructions etc, in top post …

p.s. if you install let me know if you can get the test patch working ok…
also if your experienced with SC, Im happy to consider changed to mother.scd to make it easier for users to use.

one thing, Im particularly interested in, is less client side dependency… so that its easier to use with a remote client… e.g. currently s.freeAll will clear the mainOutput object, which is not a problem, apart from a dependency with the volume knob. (I do not want to make them permanent, to fix this)


after installing the OS and the supercollider installer, is it simple a case of putting the patch on the USB and then clicking on it to open it? does it automatically know which mother patch to use?


just put the patch in the patches directory, in the same way you would do a pure data patch.


thanks. i’m going to try it out later.


EDIT: I noticed the OS2.2TB17 and SC_install zip previously uploaded were corrupt on Patchstorage.
Ive just uploaded new versions, which work fine now (00:30 CET)


Oh working nicely, green led flashing while playing Organelle keys… “full” polyphony!! all keys - cpu %33…

ummm what else…


i just downloaded but inside the SC_install zip, after unzipping, there are some other zipped files, and some of them don’t seem to unzip. it’s seems odd. can you check?


you only need to unzip the file you download off patchstorage, then transfer the entire folder over to /usbdrive/system … don’t unzip/touch anything in that folder :slight_smile:

I tested it last night it’s fine
(Just make sure you downloaded after midnight last night :))


i ran it from ‘patches’ (right?) then a black screen comes up on the LED


the new OSTB17 installed fine, but the SC test patch isn’t working.


SC_install has to be copied into /usbdrive/System (make the directory if it does not exist), and then run.

the test patch has to just be unzipped into usbdrive/patches just like any other patch
if you dont see the patch, then its because OS2.2TB17 isn’t installed (but I think this is not your problem)
if the screen goes blank, and you dont see it saying “SuperCollider loading” , then this is because Supercollider is not installed (SC_Install)


ah! okay! got it!

after making a ‘System’ folder to install from it installs fine, and the test patch works fine now too.

thanks! :slight_smile:


cool, I think for TB18, I’m going to create support for ‘installers’ in mother host, as currently its a bit inconsistent - need to make it simpler for end users :slight_smile:


I am going to try to make a version that runs inside of Pd most likely with shell
Unless i missed something, i thought this was going to work inside of Pd but perhaps i was not following closely enough granted i was busy so i am compiling a version for that just in case that will run like FLuidSynth or Csound will inside of the Pd application etc…


Why? that makes absolutely no sense to me…

Why would you want to have the overhead of PD, when you already have the overhead of sclang and scsynth.
remember Organelle is single core, so it cannot even spread the multiple processes across cores, so your sclang/scsynth and pd process will all compete for the same resources (cpu and memory!)
lets also remember that PD is started as a rt process, so thats going to make it even worst.

and having seen the processor usage of sclang/scsynth, you dont have enough to spare to run pd as we’ll, if your thinking of running a pd patch as well :wink:

this is why I extended mother host… so the user does not see the difference between running an SC patch

and yeah, I think the same is true of Csound, and fluid synth, both would be better off running as separate native processes without the overhead of PD.

anyway, if you really do want to go down that route:

  • make sure you give sclang a standard input stream otherwise it will crash… that was the issue I had getting it working in the first place.
  • you wont be able to use mother.scd, as if you launch mother.pd , you are going to grab the udp ports required for sclang to communicate with the mother host… not sure how your going to cope with that, except by creating a different mother.pd… and that has its own complications.
    (communicating sclang -> pd -> mother host via osc, will incur yet more latency)


because i think the way i am going to use pd is going to be more like effects for pd
from my experience so far i am not seeing that many folks who are going to code S3 from scratch, and those that are will most likely navigate towards your version

i am not going to use mother.scd, i am going to use pure data to host it [if successful of course]
I am also going to reach out to Sam Aaron as he seems to have solved a bunch of these issues with Sonic-pi

Currently i am updated to gcc-6 to deal with other issues then i will get to Sc

thanks for the caveats


Sonic PI is essentially an interpreter, and sclang replacement (there are others) - what ‘issues’ do you think it solved, that relate to this?

I still don’t get what role you see for PD, what does it give you?

so you want to run audio rate code in pd, then pass it to scsynth?
(this is the only reason i see to want to host SC within PD but…)

i suppose you could ‘easily’ write a PD external which launched scsynth, and got it to load an existing synthdef, or even embed an interpreter… the later could ‘solve’ the control aspect.

but it still doesn’t resolve the two bigger issues:

  • how are you going to transfer the audio from the PD process into the scsynth process?
  • running PD audio and scsynth requires two processes to run at real time priority, on a machine with only one core (and not even a hugely powerful one at that).
    Id assume for all but trivial PD and scsynth combos, you’re gonna get audio dropouts.

note: neither sonicpi nor sclang (or other sc frontends) face these issues, as they don’t process audio, that’s all done in scsynth.


my idea is to just keep it in pd for control and the externals/ease of use. I am sure the SC wizards lurking here will love what you’ve made it and they will use it. i have literally hundreds and hundreds of SC patches i made/used that i can release [i used Supercollider in a group from 2004-2007 and my handle in the group was SuperCoLiar so i did everything from spectral to breakbeats with it but i want to use it WITH pd and i think the process hit will be based upon what does what so to speak.

secondly, i just mentioned this and it’s NOT on the top of my list, i just thought you were making an SC_install similar to what oweno did with Fluid.

My next main feature addition i am actively working on is gendy~ A, as opposed to Gendy~ B and then Using Csound6~ with pd and then RTCmix~ for Physical Modeling and THEN SC