Poll: How do you modify your supercollider startup.scd?

Hi all,
I'm starting to add some more configuration management into my ansible installer for linux, and I'm trying to get a handle on what the common modifications are to the supercollider startup.scd to see where it's useful for me to focus my development:

How do you modify startup.scd?
  • add custom sample directories
  • change number of Output busses
  • change number of Input busses
  • change s.latency
  • change other s.options.*
  • add synthdef(s)
  • add midi input handling
  • add midi output mapping
  • other (please give some details!)

0 voters


I voted for everything apart from s.latency. Actually in my experience, changing s.latency doesn't do anything.

One other thing is sometimes I set an environment variable to connect things up to reaper.


I don't actually do this in my startup.sc, because I move between configurations too much.. I have a couple of files with different configurations that I run manually.


I voted for the "other" option, that's why I would like to give some examples of mine:

  • Adding NetAddr (some MIDI to OSC sendMsg mapping)
  • Adding a LinkClock for synchronizing to Ableton
  • Adding other Quarks (beside SuperDirt)


s.options.numBuffers = 1024 * 256;
s.options.memSize = 8192 * 32;
s.options.maxNodes = 1024 * 32;


Also set up some custom 'event shortcuts' using miSCellaneous library, not really releveant to Tidal
1 Like

MIDI out / buffer size / sample rate

1 Like

Thankyou guys!

What I was hoping for was some clear standouts (which there is one, but have already implemented custom sample dir handling), but what I wasn't expecting was the hot tips, eg

I'll dig into these when I get the chance (might need to ask some q's) - thanks again :slight_smile:


+1 upvote for Ableton LinkClock. i don't know what this is but i reckon i need it :rofl:


@mrreason you helped me set up Carabiner last year but it turned out it was easier/simpler for me to just use the midiclock function in Tidal with the s.midilatency command in SC to sync things up but if there's a dedicated SC quark for Ableton Link, maybe you could send me the docs on how to implement.

@nilhartman ^are you using this as well?

1 Like

I use the latest Carabiner build, I wasn't aware of the midiclock function ! :smiley:

Actually for me it's enough to evaluate something like
l =LinkClock.new.latency_(Server.default.latency); in SuperCollider when carabiner is running.

You don't need to install a new Quark because with SuperCollider 3.11.0 everything is already inbuild (see LinkClock | SuperCollider 3.12.2 Help) :slight_smile:

And for a more theoretically background @specht shared a presentation:


Thanks !
Is it now possible to sync transport ? Would be incredibly handy !

I think we should discuss this LinkClock topic in another thread. :slight_smile:

Is it now possible to sync transport ?

It is possible even if there is no one size fits all solution.

My basic idea here is to send a MIDI message to SuperCollider and on the next beat (determined by the LinkClock) send it as a MIDI message to Ableton (to control the transport) and as an OSC message to Atom (in Atom you can use OSC messages to evaluate your code).

But there would be various other possibilities and this is just one that can be implemented relatively quickly and should suffice for most purposes. And to have something else for this thread: something like this also goes into my startup.scd script :slight_smile:

1 Like

Update for this morning:
midi client handling added, just add your midi clients to the vars/all.yml

(related commit)

A hot tip from c_robo on discord I thought I'd add:

NOTE: These are mp3 files. By default, SuperDirt only loads the file extensions defined in ~dirt.fileExtensions (unchanged, it's set to [ wav, aif, aiff, aifc ]).

However, you can change the defined array to include any format compatible with libsndfile.
If you redefine ~dirt.fileExtensions to include mp3 by evaluating
~dirt.fileExtensions = ["wav","aif","aiff","aifc","mp3"],


Timing is handled by tidal (this is on purpose). So setting server latency should hopefully not change anything for Tidal ...


~dirt.dropWhen = { ~dirt.server.statusWatcher.peakCPU > 5 }; // limit to 5 % cpu

I have this, which is useful for stopping a backlog of events start jamming up Tidal. I find this happens more so during live streams or with super complicated/intensive patterns


Very handy!