#1

What are the steps needed to run supercollider code in sclang and get audio from the norns outputs (main out on shield)?

I attempted the following:

  • stopped norns systemctl units.
  • started jack /usr/bin/jackd -R -P 95 -d alsa -d hw:0 -r 48000 -n 3 -p 128 -S -s
  • started sclang (in separate ssh window)
  • ran a simple test like { SinOsc.ar(); }.play; which returns -> Synth('temp__1' : 1012) but no sound from outputs.

Do I need to route the output somehow?

#2

20 characters of did you start the server?

#3

server is running

sc3> s.serverRunning
-> true
#4

then try running

jack_connect SuperCollider:out_1 system:playback_1
jack_connect SuperCollider:out_2 system:playback_2

in a separate terminal. might be that crone classes disconnect JACK ports when the interpreter is started.

1 Like
#5

bingo!

fantablous. Thanks!

#6

On Norns, scsynth is routed through crone and not to the system playback Jack ports. So you wont hear it if crone is stopped.

Iirc the mechanism to makethe server not connect to system is the env variables set here https://github.com/monome/norns/blob/master/sc/core/Crone.sc#L42

You can issue jack_connect to connect running scsynth, or edit the lines that do this in Crone.finishBoot method

2 Likes
#7

Not specific to this question, but is there a likely culprit for these errors from a ugen:

JackEngine::XRun: client = SuperCollider was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = SuperCollider was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
#8

Those look like yer basic xruns because the ugen is too slow

Jack is just telling you that scsynth didn’t finish calculating an audio block on time

First step might be making sure you compiled a release build, etc.

1 Like
#9

will check that.

follow up to the question above.

In this same context of testing - how do I access audio in? is there a default variable? I tried in_b[0] but its not defined.

Oh - i probably have to route those as well with jack_connect, yes?

EDIT: to wrap this up.

setup the routing with this
jack_connect SuperCollider:in_1 system:capture_1
jack_connect SuperCollider:in_2 system:capture_2

and then using the following for my input in sclang
SoundIn.ar([0,1])

#10

no, in_b is a property of a CroneAudioContext

[ed]

yes, use In.ar(index) to route audio from a Bus, SoundIn.ar() as a convenience to automatically get bus indices corresponding to JACK inputs. (see the helpfiles for In, SoundIn and Bus to understand this better.)

the array argument in SoundIn.ar([0, 1]) means you will get a stereo signal, which is represented by an array of values in a SynthDef graph. (see the help doc on Multichannel Expansion.)

1 Like
#11

Excellent thanks!

I recompiled the ugen with cmake --build . --config Release and tested again. As soon as I throw audio input at it, it throws xruns like crazy.

A side effect of this (as mentioned in discussion on the mi-Ugens thread) is that this appears to kill the K1, K2, K3 button functionality (but not encoders).

Trouble is there’s no debug/output of the xruns in maiden, so it was a bit tricky to figure out where the buttons were going wrong.

#12

this is probably a job for off-norns development. you are doing c++ now and you gotta tool up. all kinds of things could be happening like smashed memory in addition to things that are just too slow.

  • use a debugger to attach to a running scsynth with debug build of the plugins. this is easy with xcode on mac. on linux with GDB its fiddlier but doable.

  • use profiling tools to identify where the ugen is spending most time. this is maybe even fiddlier to set up with plugins but again, xcode is friendliest.

doing these things remotely with a running norns is the least friendly.

yeah, maiden is not designed for this level of development.

1 Like