fundamental point of architecture:
start.sh simply wrap stdio for matron and sclang processes in websockets so maiden can use them. if you want to see their IO on the terminal, just run the processes directly
cd ~/norns
./waf
./build/matron/matron
and maybe in another shell session,
sclang
depending on your environment you may also need export JACK_NO_AUDIO_RESERVATION=1 (before running sclang)
or, of course, use maiden and the normal launch sequence - maiden’s REPL tabs will show you sclang and matron output, including the UDP and classpath errors like the ones you just posted. ( you could i suppose roll your own websocket interface - a step i am about to write up in the scripting thread for another user - though this is not really a “first step” kind of manouver.)
you can definitely use the dev branch right now but it may take some fiddling. i appreciate seeing the issues people run into as it helps prioritize what changes to make on the dev branch. i’d like it to always be working “out of the box”, but it’s not always easy to do this esp. during the work week (tehn and i have both been travelling) and espeially not for all DIY environments. (at minimum we would probably have to add some small script to clean up the SC paths - which, yes, should be done, but isn’t top priority given that end-user updates will require something different.)
at the moment, any pull from norns:dev will likely involve some fiddling with SC classpaths, so be warned.
i do think it’s worth taking the step ASAP since 2.0 has so many improvements for stability, performance, and functionality - network manager, new kernel, new audio framework.
cleaning up device handling (the topic of contention above) is high priority for 2.1, 2.x, along with other crusty parts of matron (cairo threading, coroutines for lua functions that block.)
small, kinda pedantic point:
i see sclang, scsynth, supernova, and supercollider used above in ways that are sometimes accurate, and sometimes misleadingly interchangeable. to make it clear in case you are new to SC:
sclang - the process that runs the “supercollider language” interpreter and REPL. typically sends/receives OSC on port 57121. sclang is a multi-paradigm language which uses both compiled classes and runtime evaluation - currently on norns we only allow execution of code in classes, but this may change.
scsynth - one of the two supercollider “audio server” implementations. jack client with single-threaded audio processing. typically on port 57120. sends/receives a customized dialect of OSC - “server commands” can be strings or 32-bit integer IDs. it has a very minimal DSP graph language consisting of, effectively, opcodes and connections. we used scsynth on norns to begin with, and recently switched back to it.
supernova - a newer, alternate implementation of the supercollider audio server. API is mostly identical, but uses multiple DSP threads. we switched to supernova on norns at one point, to take advantage of parallel processing for polyphonic stuff. but ultimately we found too many stability problems that seemed related to DSP worker thread scheduling on ARM, and for 2.0 we are switching back (to scsynth) and managing core load differently (with multiple audio processes.) if you are using a different environment from monome norns (in particular, something based on x86) then it might be desirable to use supernova - the norns SC environment can support either, with minimal changes to the Crone.startBoot and Crone.finishBoot methods ([https://github.com/monome/norns/blob/dev/sc/core/Crone.sc#L67])
supercollider should normally be used to reference the combined system of sclang plus one of the server implementations.
its possible to run a SC server process by itself and do all synth management with low-level server commands, but we don’t do this on norns - you need to put in quite a bit of work to develop a client that can build synthdefs for example.
