SynthDescLib not reading on startup

Lately I have to evaluate SynthDescLib.read manually after [re]compiling the class library because it won’t automatically load the synthdefs that are stored in the SynthDef.synthDefDir.

Does anybody know what could be causing this issue? Is it a configuartion thingy? Where/What should I check/set?

Cheers

I’ve just retested, and it appears to be normal behavior. Nothing calls SynthDescLib.read automatically during language startup or server booting. The more common usage is that SynthDefs are 'add’ed at runtime, not read from .scsyndef files.

I’d suggest adding it to your startup.scd if you need it to be done every time.

hjh

What is the use of SynthDef.store, then? Doesn’t it make sense to have a set of fixed synthdefs you commonly use wihtout having to load them everytime? Or you mean to load them via SynthDescLib.read?

Anyway, thanks for pointing it out.

That’s a good question :wink:

Just as a matter of opinion, I think in most cases there is no particular benefit to a library of SynthDefs saved on disk vs a library of SynthDefs in startup code. Some years ago, we added a ServerBoot action to SynthDescLib so that all SynthDefs .add’ed to the library are sent immediately after boot. This means for normal-sized SynthDefs (up to 200 or 300 UGens) there is no practical difference between

a/ scsynth reading .scsyndef files at startup and sclang reading them into the SynthDescLib

or

b/ SynthDefs being added into the SynthDescLib during language startup, and sent to scsynth during the boot process.

My own preference is to compile SynthDefs as needed – I really strongly dislike creating unnecessary disk files, and, when I start the environment, I don’t necessarily know what music I’m going to play, and I don’t want to load too many SynthDefs that I’m not going to use. So, except for a few utility SynthDefs, my SynthDef code is in performance initialization files.

Now, there is one concrete reason to use disk files: big synthdefs. Optimizing and sorting units in a big synthdef is quite slow – you don’t want to incur that cost every time you start the language. Reading the SynthDesc from disk is much faster. But you really need to get up to a couple thousand UGens before you see the benefit. Or massive numbers of SynthDefs.

(
bench {
	SynthDef(\bigun, {
		Out.ar(0, Array.fill(10, { SinOsc.ar(0) * 0.1 }).sum)
	})
};
time to run: 0.0053464200000235 seconds.

bench {
	SynthDef(\bigun, {
		Out.ar(0, Array.fill(100, { SinOsc.ar(0) * 0.1 }).sum)
	})
};
// 10x more UGens, about 10x execution, still very fast
// not really much reason for a disk file here
time to run: 0.049296185000003 seconds.

bench {
	SynthDef(\bigun, {
		Out.ar(0, Array.fill(1000, { SinOsc.ar(0) * 0.1 }).sum)
	})
};
)
// 100x more UGens, 1000x slower(!)
time to run: 3.069122291 seconds.

(What’s really slow here, btw, is that the Array builds a chain of (a * 0.1) + (b * 0.1) + (c * 0.1) and all of these get optimized into MulAdd units.)

FWIW, I found the original version of SynthDescLib (16 years ago!) and it doesn’t read automatically from disk. https://github.com/supercollider/supercollider/commit/be72d626c28a24ec6a4198915a717eee8a85a5c5#diff-f4536faec50f905b53a0c21a4a2fc2d7R200 So it looks like that was never the intent.

If you put SynthDescLib.read; into your startup.scd file, then it will be done every time you recompile.

hjh

1 Like

Makes total sense. Thanks!