I’m happy to tell you that today i successfully managed to install SuperCollider on my Organelle. So far i’ve only tested that it makes sound. The next part would be to make it work with the hardware and the file system.
Below are the steps i took to do this (i hope i remember everything correctly). You will need a hdmi monitor, a keyboard and a mouse as well as a working wifi adapter providing Internet connection to do this. Check this thread for the wifi. I’m a noob when it comes to Linux so there are probably things you could improve in this guide. Please chime in with your thoughts!
Building SuperCollider from source on the Organelle
Setup wifi & get write permissions (thanks to oweno and joshuaguild for the help here)
sclang #should start sc and compile the class library with only 3 harmless class overwrites warnings
s.boot #should boot the server
*a= {SinOsc.ar([400, 404])}.play #should play sound in both channels. NOTE: this could get loud since it’s not affected by the Organelle’s volume control at this point!
BTW: I read here that "If main.pd is not found, it will look for ‘run.sh’ and execute it. So a patch doesn’t necessarily need to be created in Pd"
So, i created a folder on the USB-stick called TestSC to see if i could start sc that way. In the folder i have a file called run.sh (nothing else) containing this script:
#!/bin/bash
jackd -R -P90 -p16 -t200 -d alsa -dhw:0 -p 128 -r 44100 -s -i2 -o2 &
sclang
Wow this is great! good job getting it running! I’d love to try this out.
The instruction about putting a run.sh in the patch folder is unfortunately a little obsolete and not really accurate. We intended to build in this capability, but we were always focusing on Pd patches so didn’t get around to implementing it.
It is an easy fix however, but will require re-compiling the mother program (/root/mother) that runs the menu interface and launches Pd patches. The program is here:
downloading and running ./compile will spit out a new mother binary you can replace at /root/mother (alternatively you can place the new binary on the USB drive at /usbdrive/System/mother, on boot up the Organelle checks there for an alternate mother before running /root/mother). It is a fairly simple program, and you would just have to make some changes in the function runPatch (line 104) of this file:
Thanks for clarifying! I finally had some time to test this a little more, but it seems i cannot compile. I’ve made some changes to the UI.cpp that i want to try, but as far as i can tell it’s not those that causes errors and warnings. This is what i get when running ./compile:
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
UI.cpp:91:36: warning: conversion from string literal to 'char *' is deprecated
[-Wc++11-compat-deprecated-writable-strings]
auxScreen.drawNotification(" System Info ");
^
UI.cpp:176:37: warning: conversion from string literal to 'char *' is deprecated
[-Wc++11-compat-deprecated-writable-strings]
menuScreen.drawNotification("Select a patch...");
^
UI.cpp:230:5: error: no member named 'setlocale' in namespace 'std'; did you mean simply 'setlocale'?
std::setlocale(LC_ALL, "en_US.UTF-8"); //JAG KOMMENTERADE UT DETTA PGA FELMEDDELANDE!
^~~~~~~~~~~~~~
setlocale
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/locale.h:53:8: note:
'setlocale' declared here
char *setlocale(int, const char *);
^
2 warnings and 1 error generated.
SLIPEncodedSerial.cpp:27:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
1 warning generated.
Serial.cpp:86:39: error: use of undeclared identifier 'B500000'
set_interface_attribs (serial_fd, B500000); // set speed to 115,200 bps, 8n1 (no parity)
^
1 error generated.
OSC/OSCMessage.cpp:604:13: warning: enumeration value 'DONE' not handled in switch [-Wswitch]
switch (decodeState){
^
1 warning generated.
OSC/OSCTiming.cpp:152:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
1 warning generated.
So, i tried to comment out the lines that caused errors but there’s still no new mother binary created as far as i can tell. Any ideas?
It looks like you are attempting to compile it on a Mac, is this correct? You need to compile it on the Organelle itself, or else install an ARM cross compiler environment. A cross compiler is possible, although we have always just compiled directly on the Organelle because it is simpler.
Hmm… I still can’t get it to work, trying to compile on the Organelle. Where is the new binary supposed to end up? In the same directory?
What i did now was to copy my edited version of the folder “Organelle_UI-master” to the Organelle Desktop. Then cd /root/Desktop/Organelle_UI-master
and ./compile
Getting a lot of warnings like
UI.cpp: In member function ‘void UI::runSystemCommand()’:
UI.cpp:91:59: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
auxScreen.drawNotification(" System Info “);
UI.cpp: In member function ‘void UI::drawPatchList()’:
UI.cpp:91:59: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
menuScreen.drawNotification(” System Info ");
OSC/OSCData.cpp: In member function ‘int32_t OSCData::getInt()’:
OSC/OSCData.cpp:173:16: warning: converting to non-pointer type ‘int’ from NULL [-Wconversion-null]
return NULL;
It does throw some warnings about the string constants, but if it gets through without errors, it worked. The new binary is in the same folder, called ‘mother’. you can do a
rm mother
to trash the old one, then
./compile
should spit out a new one?
The quick and dirty way to run the new one is to kill the old one
Oh, now i checked the compile script and it does indeed output a new binary, but it is called main. Is this just an old name for mother maybe? Or is main needed too?
I did try to change the script to output mother instead, and to put it in /usbdrive/System as well as in /root but something’s not working. The encoder and the display becomes unresponsive when i use my own version of mother for some reason.
I’m not fluent in c++ so it’s difficult for me to know what to check. I’ve only modified these lines in the runPatch function of UI.cpp file like this:
//sprintf(cmd, PATCHES_PATH"/%s/main.pd", menuItems[selectedPatch]);
sprintf(cmd, PATCHES_PATH"/%s/main.scd", menuItems[selectedPatch]);
printf("Checking for Patch File: %s\n", cmd);
if (checkFileExists(cmd)) {
// check for X,
// run pd with nogui if no X. also use smaller audio buf with nogui
// the rest of the settings are in /root/.pdsettings
if(system("/root/scripts/check-for-x.sh")){
printf("starting in GUI mode\n");
//if (checkFileExists(PATCHES_PATH"/mother.pd")) sprintf(cmd, "/usr/bin/pd -rt -audiobuf 10 "PATCHES_PATH"/mother.pd \""PATCHES_PATH"/%s/main.pd\" &", menuItems[selectedPatch]);
if (checkFileExists(PATCHES_PATH"/main.scd")) sprintf(cmd, "jackd -R -P90 -p16 -t200 -d alsa -dhw:0 -p 128 -r 44100 -s -i2 -o2 \"sclang -D "PATCHES_PATH"/%s/main.scd\" &", menuItems[selectedPatch]);
//else sprintf(cmd, "/usr/bin/pd -rt -audiobuf 10 /root/mother.pd \""PATCHES_PATH"/%s/main.pd\" &", menuItems[selectedPatch]);
else sprintf(cmd, "jackd -R -P90 -p16 -t200 -d alsa -dhw:0 -p 128 -r 44100 -s -i2 -o2 \"sclang -D "PATCHES_PATH"/%s/main.scd\" &", menuItems[selectedPatch]);
}
else {
printf("starting in NON GUI mode\n");
if (checkFileExists(PATCHES_PATH"/main.scd")) sprintf(cmd, "jackd -R -P90 -p16 -t200 -d alsa -dhw:0 -p 128 -r 44100 -s -i2 -o2 \"sclang -D "PATCHES_PATH"/%s/main.scd\" &", menuItems[selectedPatch]);
//if (checkFileExists(PATCHES_PATH"/mother.pd")) sprintf(cmd, "/usr/bin/pd -rt -nogui -audiobuf 4 "PATCHES_PATH"/mother.pd \""PATCHES_PATH"/%s/main.pd\" &", menuItems[selectedPatch]);
//else sprintf(cmd, "/usr/bin/pd -rt -nogui -audiobuf 4 /root/mother.pd \""PATCHES_PATH"/%s/main.pd\" &", menuItems[selectedPatch]);
else sprintf(cmd, "jackd -R -P90 -p16 -t200 -d alsa -dhw:0 -p 128 -r 44100 -s -i2 -o2 \"sclang -D "PATCHES_PATH"/%s/main.scd\" &", menuItems[selectedPatch]);
}
I also tried without the if statement that checks for a mother on the usb, since i believe it’s unnecessary with sc. Easier to do all the OSC communication within the same piece of code.
Another thing i did was to add a killall sclang and killall jackd to the script killpd.sh but i fail to understand how any of these changes could cause the unresponsive encoder/display…
No, i don’t get that far. With the original mother running it works fine running an sc patch (from terminal) with knobs working and all. The Info states that the cpu is at 100% though, but i’m pretty sure it isn’t. But this might be another story…
When i switch to my modified mother the encoder and display stops working immediately. If i boot the Organelle with the modified version the display freezes at “starting: 99%”. I can still continue working with the terminal though, and if i do a killall mother and start the original one everything works again.
So, it’s the patch selection that doesn’t work basically. Ideally i would like it to work with both pd and sc patches, but i thought i should start by just checking that it works with sc.
OK… also that it hangs on boot up with the new version makes me think something is wrong with new version you compiled because the first thing it does when you run it is communicate with the hardware and OLED screen, and looks like it doesn’t even get that far…did you attempt compiling and running the program before making any modifications? this might be worthwhile to see if it was a change you made or a problem with compilation / runtime…
I tried that and it works. So probably it’s my changes that somehow causes the problem. Which files and/or scripts are involved in the hardware communication? Is everything done inside mother? Could the code above call something that needs to be changed as well maybe?
Do i need to load mother.pd even if i’m not using pd? No?
If all you changed were a couple lines in the runPatch function it should still run since that function only gets called when the encoder gets pressed, so that is strange, I’ll have to try it myself…
You won’t need to start mother.pd, you should be able to do everything from inside SC, assuming you can receive OSC on port 4000. mother.pd just translates OSC input into regular Pd messages. You can verify that the mother program is sending osc messages by dumping them:
oscdump 4000
Will print the messages coming from knobs and keys.
Yes, the OSC works fine already when starting jack and an sc test patch from the terminal.
I’ve solved the issue with the freezing display. I don’t know how though. I just threw away the faulty one and started over and with a little help from a friend it can now run the pd patches as before, and at least it tries to open sc now. It’s not working properly yet. But i’m getting closer…
Is there a restriction somewhere that could prevent mother from starting supercollider? I’ve now added the lines system("jackd -R -P90 -p16 -t200 -d alsa -dhw:0 -p 128 -r 44100 -s -i2 -o2 & "); system("sclang"); // also tried with the full path which is /usr/local/bin/sclang
and jack starts fine but supercollider doesn’t. Any ideas? Is /usr/local/bin/ a restricted folder or something?
I’ve tried all of this now, unfortunately without luck. With the script it doesn’t open anything. One thing i noted was that the new mother i compiled is owned by a user called alarm (and so is everything else on /usbdrive it seems. Should this be root instead? sclang is owned by root.
Edit: Changed owner to root, but that doesn’t seem to make a difference…
So far i’ve only tested that it makes sound. The next part would be to make it work with the hardware and the file system.