Supercollider headless autostart and/or single_click.sh

Giedrius · December 4, 2017, 8:02pm

Hey! Great to hear it worked!

You may contribute the new scripts to the Pisound repository, by forking it and creating a pull request once the changes are applied.

You could use the Pure Data as an example. The ‘common’ folder has 2 scripts which define start_puredata and stop_puredata shell functions which are common for The Button and the Pisound App. The start function expects to get the full path to the patch to start as the first argument. The stop function kills all Pure Data instances, in the future this may change to deal only with the exact instance that was started by The Button or the App. (so you should kill all sclang instances in your stop script at this time).

The actual ‘entry point’ scripts for The Button are in here: https://github.com/BlokasLabs/pisound/tree/master/scripts/pisound-btn

The Button specific start_puredata.sh script then includes the common script: . /usr/local/pisound/scripts/common/start_puredata.sh. (The repository is checked out by default to /usr/local/pisound/ during Pisound software setup.) Then it goes on doing The Button specific things, like searching for a Pure Data patch to load in various locations, and once found, invoking the common start_puredata function.

The button actions in pisound-config are populated based on the script filename, so if you’d create /usr/local/pisound/scripts/pisound-btn/start_supercollider.sh, you’d get Start Supercollider entry in the script picker menu.

Feel free to ask us any questions.

thetechnobear · December 5, 2017, 6:13pm

yeah I had the trouble with the default group not initialising in time.
and found the root cause was (or seemed to be) a couple of timing issues between sclang and scsynth

what ive resorted to is

// boot the server
s.boot;
s.doWhenBooted {
	(
        Routine( {
               1.wait;
		~mainOut = ~mainOutDef.add.play;
		~mainPatch.load;
        }).play;
	)
};

theoretically, wait is not required, but in practice I found that without it the default group would not be ready for the first synth to play…

fyi… here what I’m doing is… having a central output for the hardware, so i can do fun stuff, like measure intput and output audio peaks (i should rename mainoutput to hardwareIO or something ;)) , then what i do is actually load the ‘real’ patch file.
this is for the Organelle, so allows me to basically launch different patch files whilst having a central patch file for dealing with hardware configuration.
(you can see more details over at the organelle.io forum)
i plan to do the same thing on the pisound once ive ironed out the issues on the Organelle.

thetechnobear · December 5, 2017, 9:19pm

talk of coincidences I was researching another issue with SC (not deallocating synths correctly!)
and found this bug report

it appears 3.9 (beta1) has a known issue, with waitForBoot and doWhenBooted.
its quite a long bug report, so can quite determine if they think a solution will be found for 3.9.0 or if its going to wait till 3.9.1… but seems the workaround I’m using might be temporary which is good news.

telephon · December 10, 2017, 8:18pm

It bothers everyone, it’ll be fixed soon. There is a branch that has the fix in it already, if necessary: https://github.com/adcxyz/supercollider/tree/lockClientIDWhileRunning

blueprint · January 29, 2018, 10:33pm

Just a tip for people looking to find a stable supercollider env… I use:

It’s stable 3.9 (alpha, I think). I do not have problems with waitForBoot I’m working on some more button scripts … will postem soon

The startup (from a reboot cron) is simply:

sudo sclang /home/pi/prynth/sc/main.scd

main contains

s.waitForBoot{
“system.scd”.loadRelative;
s.sync;
“user.scd”.loadRelative;
};

system.scd contains (but most of you don’t need it

fork{

~sounds = (
path: PathName.new(“/home/pi/prynth/server/public/sounds/”)
);

80.do{ | i |
// i.postln;
Bus.new(‘control’, (100+i), 1);
};

s.latency = 0.05;

};

and then comes whatever scd file (user.scd) you want.

This works for me without hitches.

blueprint · February 4, 2018, 11:17pm

Just a quick update … using the latest prynth image and after installing pisound AND with a bit of tweaking (for instance copying quarks into a node_module context) I have a really solid 3.9 auto run env AND the supercolliderjs editor.

Slick … I’m doing granular arpeggiator nonsense to the nines and, frankly, it’s more fun with the pi than with the laptop …

The jack settings need to be tweaked a bit more … but the the whole stack is basically started and run via node. WTF. a javascript server. but it reduces the boot cron (pi user crontab) to starting node.

grab this image (or get the code from github if you want to go the extra mile) and edit the wpa_config while the image is mounted … and PM me with questions

I’ll try to do a write up soon but it’s really the nicest/easiest way I’ve found to run supercolider with the pisound.
AND it sounds GREAT!

blueprint · February 6, 2018, 7:36pm

Ok, now the really sweet part. Autoloading works with Zero pain. Button scripts are TRIVIAL …

Since it’s supercolliderjs you do the following (for button pressed once):
curl http://localhost:3000/interpret --data-urlencode code@/home/pi/prynth/server/public/supercolliderfiles/1.scd

sh script could be as little as that (if you don’t care about led feedback) …

In short, you can load and execute directly via http POST requests …

Man I love this thing. It’s more stable than my thinkpad And this thing is a properly tweaked RT kernel

blueprint · February 6, 2018, 8:41pm

Hmmm. Gotta open a thread. I’ve formalized my approach to using the prynth image (http://idmil.org/pub/software/prynth/2017-09-21-prynth.img.zip).
The buttons script is more or less the same as that from blokas for the moddep:
I’m NOT posting the header, it’s GPL and I state, my version is is also GPL, V2…
here it is:
CUR_DIR=$(dirname $(readlink -f $0))

. $CUR_DIR/../common/common.sh

log "pisound button clicked $1 times!"

log "Loading `expr $1 - 1`"
# following is the original
#python $CUR_DIR/modep-ctrl.py index `expr $1 - 1`

# now to control supercolliderjs under prynth

FREE="$(curl -s http://localhost:3000/interpret -d 'code=s.freeAll;')"
START="$(curl -s http://localhost:3000/interpret --data-urlencode  code@/home/pi/prynth/server/public/supercolliderfiles/${1}.scd)"

#if [ $? -eq "OK" ]; then
if [ $START = "OK" ]; then
	for i in $(seq 1 $1); do
		flash_leds 1
		sleep 0.3
	done
else
	flash_leds 50
fi

dormirj · February 23, 2021, 1:48am

Thanks blueprint, I’ve been struggling with a reliable startup procedure for supercollider scripts, the prynth os seems to be a very good step in the right direction. I was wondering though, did you use the kernel provided by prynth or the patchbox one?

Moctezuma.dev · March 7, 2021, 4:30pm

Hi everyone,

I got my card last Thursday and struggle a bit to make it work with supercollider from command line, I’ll share my script for anyone who faces the same problem in the future.

So under /usr/local/pisound/scripts/pisound-btn

I created two new scripts:

start_sclang.sh

#!/bin/sh

. /usr/local/pisound/scripts/common/common.sh

export XAUTHORITY=/home/pi/.Xauthority
export DISPLAY=:0.0
export JACK_NO_AUDIO_RESERVATION=1

log “Display Set”

sudo su - patch -c “/usr/bin/jackd -P75 -dalsa -dhw:pisound -p64 -n2 -s -r48000 > /home/pi/jack.log 2>&1 &”

sleep 4

sudo su - patch -c “export QT_QPA_PLATFORM="offscreen"; sclang -D /home/pi/start.scd > /home/pi/sc.log 2>&1 &”

flash_leds 100

stop_sclang.sh

#!/bin/sh
. /usr/local/pisound/scripts/common/common.sh
flash_leds 100
sudo su - patch -c “pkill -9 sclang; pkill -9 scsynth”
flash_leds 50

Remember to add permissions to the scripts

sudo chmod +x start_clang.sh
sudo chmod +x stop_clang.sh

Then I modified the config file /etc/pisound.conf

CLICK_1 /usr/local/pisound/scripts/pisound-btn/start_sclang.sh
CLICK_2 /usr/local/pisound/scripts/pisound-btn/stop_sclang.sh

Change the above lines to start sclang instead of puredata.

And now the last part missing… create a SuperCollider file

Create a file start.scd under /home/pi

This is the SuperCollider script that I used to test

s.boot;
s.waitForBoot({{ SinOsc.ar(440) }.play; });

restart your raspberry pi and press one to start sclang it takes a few seconds before you start hearing sound.

press the button twice and the sound should stop.

this gathers a lot of things that I read in this and other threads, it would be nice to create a module specific to SuperCollider used in the console without UI.

And I like prynth webserver idea, it would be greate to have a webclient to comunicate with the scsynth process.

Cheers!

dormirj · March 9, 2021, 1:07am

So i tried my hand in turning the autostarting of sc into a module, just starting with an empty template, but so far it doesn’t start, do i need to add something to the json file to make it actually launch the launch.sh or is it the default option with auto?

folder:

/usr/local/patchbox-modules/imported/sc-dormir

install.sh

#!/bin/sh
echo "Nothing to do for now! Thank you!"

launch.sh

. /usr/local/pisound/scripts/common/common.sh
export XAUTHORITY=/home/patchbox/.Xauthority
export DISPLAY=:0.0
export JACK_NO_AUDIO_RESERVATION=1
# /usr/bin/jackd -P95 -dalsa -dhw:pisound -p128 -n2 -r48000
# jack seems to be already started from some other dependency?
sclang /home/patch/Documents/scc/main.scd

lists.sh

empty

patchbox-module.json

{
    "name": "dormir-sc",
    "version": "0.0.4",
    "description": "dormirs supercollider module test",
    "author": "dormir",
    "launch_mode": "auto",
    "depends_on": [
    ],
    "scripts": {
        "install": "install.sh",
        "launch": "launch.sh",
        "list": "list.sh",
        "stop": "stop.sh"
    }
}

stop.sh

. /usr/local/pisound/scripts/common/common.sh
killall sclang
killall scsynth

COMMENT obviously just means “#” but the forum software doesn’t like it. am i missing something for the use as a “proper” module? main.scd is replicating the usage from the prynth startup and when i run launch.sh manually it works, but doesn’t automatically from bootup.

best—

Giedrius · March 9, 2021, 7:49am

Fixed it up for you - the ‘>’ character is for producing quote blocks, use the `code` (` is officially called a backquote) for inline code stuff, and

```
long code
some more code
even more code
```

for long code blocks. It respects whitespace too. The first line starting the code block can have a suffix indicating the language syntax highlighting if the guessed one doesn’t seem right for the contents. I usually put shell scripts using ```bash, to avoid it accenting unimportant things.

Do the files have +x permission? (chmod +x ..) Do they run if you start them from a terminal? Does the module show up in patchbox utility?

You may also check out the output of

sudo journalctl -u patchbox-init

(hit the end key to see latest stuff)

dormirj · March 9, 2021, 11:08am

aah thanks for the little posting help!

and of course also for your help with my little module. so, all scripts are executable yes, i can see and select the module in the patchbox menu, they run and work when i run them from either a ssh terminal or from the terminal inside a vnc session.

so now after your very helpful tip to check the output of patchbox-init i think i’m making some headway:

Mar 09 10:53:51 patchbox systemd[1]: Starting Patchbox Init...
Mar 09 10:53:52 patchbox patchbox[627]: Manager: sc-dormir.module activated
Mar 09 10:53:52 patchbox patchbox[627]: Manager: sc-dormir.module launch mode is auto
Mar 09 10:53:52 patchbox patchbox[627]: Manager: sc-dormir.module launched
Mar 09 10:53:53 patchbox systemd[1]: Started Patchbox Init.
Mar 09 10:53:53 patchbox patchbox[627]: compiling class library...
Mar 09 10:53:54 patchbox patchbox[627]: No protocol specified
Mar 09 10:53:54 patchbox patchbox[627]: qt.qpa.screen: QXcbConnection: Could not connect to display :0.0
Mar 09 10:53:54 patchbox patchbox[627]: Could not connect to any X display.
Mar 09 10:53:54 patchbox patchbox[627]: terminate called without an active exception
Mar 09 10:53:54 patchbox patchbox[627]: Aborted
Mar 09 10:53:54 patchbox systemd[1]: patchbox-init.service: Main process exited, code=exited, status=134/n/a
Mar 09 10:53:54 patchbox systemd[1]: patchbox-init.service: Failed with result 'exit-code'.

now with that output i added: export QT_QPA_PLATFORM=“offscreen” to the launch.sh from Moctezuma.dev’s post and i think it’s working from first tests.

so maybe with a bit of refining and an addition of button functions (personally i would not want to use the button to start sc, because in my mind it should be a device that does its job when powered on) we could turn this into a proper module to be added at some point?

best–

Giedrius · March 9, 2021, 11:16am

If you’d like the GUI to be up, try adding "is_desktop": true, like here: Creating a Pianoteq box - #4 by Giedrius

It then launches the application as an ‘XDG Autostart’ application rather than a systemd service.

Moctezuma.dev · March 9, 2021, 9:47pm

I’m fine with both approaches, maybe both should be supported. I was looking at the puredata script if I understood properly, it tries to look for a file in a usb, so that could be an option too…

I can also see myself with multiple patchbox sd cards with preloaded synthdefs…

I already tested with my midi keyboard works perfectly, although it freezes from time to time… I’m not sure weather it’s related to supercollier or something else.

Giedrius · March 10, 2021, 1:21pm

You could check the output of sudo journalctl -u jack to see if Jack is still working when it freezes, as well as other system logs like dmesg, sudo journalctl -u pisound-init, and inspect processes using ps -ef and top.

Yes, PD scripts mount the connected USB drives and search for a patch there - this way it’s easy to swap out patches without any input other than the Button on Pisound.

Sn_Lx · March 31, 2021, 12:44pm

I wanted to try the approach you described but I fail with very basic stuff.
Like I can not save anything to the aforementioned folder or copy something into it.
Can you point me to a dummies tutorial how to get permission to my own pisound?
Maybe something Brief only to try your approach and not to get perfect in permission handling.
I try to do the stuff via VNC.

Sorry for this basic questions. All I want is a hardware device that starts a supercollider file and may programmed sound falls out of it …

Thanks in advance,
Sebastian

dormirj · March 31, 2021, 1:19pm

in a linux filesystem the enduser usually only has write-access to his/her own folder, so to edit files/create folders outside of that scope you have to either log in as a root or what is more common in contemporary debian based systems to tell the system that the next command is done with superuser rights aka “sudo command”.

if you’re running patchbox os or most other pi-specific debian based oses it should be as simple as typing in a terminal “sudo mkdir mymodule” for instance.

so the way to with my approach is to create a folder

sudo mkdir /usr/local/patchbox-modules/imported/mymodule

and create all the files mentioned in my post

sudo nano /usr/local/patchbox-modules/imported/mymodule/install.sh
sudo nano /usr/local/patchbox-modules/imported/mymodule/launch.sh
etc…

when you have all the files you should be able to enter “patchbox” into a commandline and see your new module in the module selection, just select it.

if you just copy my files, keep in mind the sc file must be /home/patch/Documents/scc/main.scd or you change the launch.sh and that you absolutely need to add
export QT_QPA_PLATFORM=“offscreen”
to the launch.sh if you want to have it autorun.

tell me if it works for you–

best

Giedrius · March 31, 2021, 1:59pm

Btw, the Patchbox module could be placed on GitHub, then it’d be a single command to install it, see this repo for an example:

dormirj · March 31, 2021, 4:17pm

alright, thanks for the reminder giedrius, i’m going to set it up when i’m back with my pisound, then it should be easier for people without much commandline experience