Something weird when not executing synthdef reverb graph function , but Synth\reverb

I accidentally didn’t execute the Reverbsynthdef , but did execute the reverbsynth
Result is that the reverb always sounded

Here’s a bit of code , execute everything except the SynthdefReverb ( do execute reverbsynth and it’s set parameter )
Result is that the reverb will always sound but it’s parameters can’t be set
How come a reverb can be active while the synthdefgraph functin isn’t executed ?
It was really driving me nuts why I heard reverb , the fx send was set to zero ( in the fmsynth pbindef) and the set parameter for the reverb didn’twork .
The node tree showed that the reverb was executed so that couldn’t be it ., but it seems that NOT executing the reveb synthdef lead to this weird situation .
So how come a not executed reverbsynthdef that houses the reverb dsp block does produce reverb ?

		var env1,env2,env3,env4,op1,op2,op3,op4,pan=(0.0),signal;[0,1,0],[op4att,op4dec],[0,-5]),doneAction:0);,env4*feedbackamt);

SynthDef(\reverb,//Don't execute 
		var sig,processed;,2);,mix,room);,processed)






Things get weirder
Here in this piece of code , just a reverb and a delay
Executing just the ~reverbarate=synth (Not the synthdef ) puts it in the server
Doing that just with the delay (~comber ) says , Synthdef not found
Been testing lot’s of effects and it seems that the Freeverb is the only showcasing this behaviour .
Long story short , not executing freeverb synthdef but only freeverb\synth always puts it on bus 0

SynthDef(\reverb,//Don't execute
		var sig,processed;,2);,mix,room);,processed)


SynthDef(\layla,/////don't execute
		var sig ,modulator,processed;,2);*modamt;,mdt,dt+modulator,dect);,hpf);,sig,xfadecontrol);,processed)


We could start with an absolute: The server cannot play a SynthDef that doesn’t exist.

So the SynthDef must have been created somewhere.

Now, in your screenshot, you can see in the server status bar, “d119” – this means the server is holding 119 SynthDefs.

If you’re starting from absolutely nothing, just opened the IDE, and you didn’t run any SynthDef().add blocks, then this means… SynthDefs exist that you didn’t create. That’s an inescapable conclusion, isn’t it? You’re saying “it’s weird” that there’s a SynthDef you didn’t execute but there’s over a hundred of them… so the assumption that “it shouldn’t exist if I didn’t run it” can’t be true, and you have to drop that idea.

Now… continuing with the process of using available information… there’s “1s” (one synth) and “40u” (40 UGens). Therefore all 40 UGens must belong to the only existing Synth.

Reading your reverb SynthDef code, I see 1 Control, 1 In, 2 FreeVerbs (btw have you tried FreeVerb2 for stereo?), and 1 Out = 5 UGens, way below 40.

So another inescapable conclusion is that it isn’t your SynthDef.

I would guess some extension class might be creating some SynthDefs at language bootup time. Or perhaps at some point in the past, you might have run a block with SynthDef(\reverb, ...).store or writeDefFile, in which case the reverb def would be read in from a disk file at boot time.


I never used write deffile .
This reverb issue Happens after closing - opening supercollider several times in a row .
Only using my own synthdefs
I did save a session with lots of tabs , but then deleted the tabs upon launch .
Perhaps this session is responsible for the numerous synthdefs?
Will see what tommorow brings after booting pc and just executing ~reverberate

You don’t know that. Actually I’d go further: You’ve already provided absolute evidence proving that there are SynthDefs in your system that you didn’t create.

Classes, during startup, can create SynthDefs. The startup.scd file can create SynthDefs.

s.waitForBoot {
	// 'waitForBoot' function is actually
	// invisibly in a Routine, so we can 'wait'

Starting completely fresh, if I do that, I get 136. (This may be a bit higher than “normal” because I know that some of my own extensions create SynthDefs.)

Based on your screenshot, I guess you will get about 119.

If it’s really true that you are “only using [your] own SynthDefs,” then this number would be 1 (for the \default def).

From this, the conclusion is that some code outside of your direct control is creating SynthDefs. You are definitely not using only your own. There is nothing you can do in a code document to prevent classes or startup.scd from creating SynthDefs.

Completely irrelevant to this question. It’s not the first time you’ve suggested that the editor’s state has some influence on the state of the interpreter. It doesn’t (well, there’s one feature, but you’re not using it). Please forget this idea :wink:


When I write ‘ only use my own synthdefs in my projects ‘ it’s means exactly what it is says !
Please don’t insinuate I am a liar because that’s how I interpretate your comment .

Have I launched the hundreds of help files in the past ?
Have I launched some code from others just too explore ?
Sure , but none are in my projects .
Make of that what you wish

Here goes , just booted PC for the first time of the daty , win 10 did an update
Went straight to this forum an copy pasted the code from my second post in supercollider
Executed ~Reverberate=synth only
Same result as yesterday , NO other synthdefs in projects
I always get 119 d in the server bar even with a clean start up , which synthdefs are those ?

More info , Made a new simple synthdef test , and gues what …119 went to 120
But upon re-launch the numer went back to 119
I really want to know whcih 119 synthdefs it’s loading

Even after start up , so supercollider keeps hem all in memory

No, it isn’t that at all.

It’s only that it’s impossible for any SC user, anywhere, to be 100% sure that they are only using their own SynthDefs.

You are executing code for specific SynthDefs, yes, I understand that.

But the reverb SynthDef you’re asking about is coming from somewhere else.

I don’t know where it’s coming from, but if you do Synth(\reverb) and it creates a synth without error, then there is a \reverb SynthDef in the system, whether you created it or some other component did.

But beyond that, it is categorically impossible to say that you are using only your own SynthDefs. There is always at least the \default SynthDef!

It isn’t about liar or not, it’s about misunderstanding. Your posts reflected a mistaken assumption and I was only trying to correct that. Nothing more. This doesn’t have to be a fight.


1 Like

Sorry for the misinterpretation , hug
Would really like to know how Reverbsynth remains on the server , or better how it’s automatically put on the server upon launch and where those other 119 Synthdefs are coming from ?
I haven’t done anything exotic yet to alter the state of SC,or build classes , I am the same dude that needed a 4 day crash course in busrouting…remember :slight_smile: , building classes is way beyond my current expertise

Try evaluating the code:;

It will open a GUI window that shows you all the SynthDefs you have available. It will also show you all the UGens used within that SynthDef, your argument names (so what you would be able to call set on to change the sound of things), inputs and outputs it has available, etc.

Here’s mine. It’s the first code I’ve personally evaluated after launching SuperCollider and having it automatically boot (via code in my startup file, which actually evaluates a whole bunch of other stuff I want it do automatically when it starts).

I have many Extensions and Quarks installed. Almost every single one of these is from them. These are often utilities that might make those libraries work the way their creators intended.

I believe what jamshark is saying is that one would assume - I have the same assumption - based on how you describe what’s happening, is that likely you’ve got some external library that might have a Reverb effect built in. That library then likely preps and evaluates those SynthDefs during startup, and invisibly.

No worries – it’s all ok in the end.

When I say “I don’t know where it’s coming from,” I mean that I don’t know specifically which class is creating it. Possibly one way to find it might be to text-search .sc files for “reverb” – I actually tried this with the main class library but didn’t find anything. Perhaps unfortunately, there’s no way to trace back from a SynthDef object to the file that created it, so it will take some manual digging outside of SC.

But… it also doesn’t entirely matter, either. If a SynthDef exists and you’re not using it, then there’s no real harm. IMO it would be worth considering how much effort it warrants to try to find this one def.

Many of the defs are defined in the class SystemSynthDefs. These are essential for some sc features; you don’t want them to go away. The reverb in your environment isn’t one of those, though.


Nothing out of the ordinary I guess
Too bad ,I can’t paste the mentined synthdefs


No reverb Ugen to be seen
it’s def. weird , just executing an fm synthdef clealy shows it in the list , just executing ~reverbsynth does not ( since the synthdef is not executed but reverb does sound
I went through all the synthdefs after executing ~revsynth and none of them showed a Ugen called freeverb

It also doesn;t sound nowhere near the freeverb even with damp to min-max ,
The default mystery reverb you hear the diffuser delays a lot more , none of the freeverb examples sound even remotly close
file 1 : dry fm sound
file 2 : mystery reverb , (no synthdef exe) and there are no settings avaiable since ~reverb.set doesn’t work
file 3 -->5 , freeverb with damp setting of 0 ,0.5,1

Well… the primary way to add a SynthDef into the list is by SynthDef(... something...).add, for instance, “executing an fm synthdef.” OK.

But ~reverbsynth is Synth(\reverb), right? It’s a totally different construction… so there is no reason to expect it to do the same work as SynthDef. (Synth never adds a SynthDef.)

I realize it might be a little pedantic to pick at these details – at the same time, I can’t tell whether it’s merely a mistaken choice of word, or whether it reflects concepts that have gotten muddled in your mind. If it’s the latter, being more precise about language could help to un-muddle the concepts.

In any case…

Here is a way that the known symptoms can be reproduced.

// 'store' uses a file on disk
// the file stays on disk afterward
SynthDef(\boop, { |out, freq = 440, time = 0.1, amp = 0.1|
	var eg =, time), doneAction: 2);
	var sig =;, (sig * eg * amp).dup);

// start from scratch -- clear existing in-memory objects

File.exists(SynthDef.synthDefDir +/+ "boop.scsyndef");
-> true  // file is still there\boop);
-> nil  // 'boop' is not in the SynthDescLib (i.e., not in that GUI)


Synth(\boop);  // sound + no error\boop);
-> nil  // 'boop' is still not in the SynthDescLib;\boop);
-> SynthDesc 'boop' 
ControlName  P 0 out control 0.0
ControlName  P 1 freq control 440.0
ControlName  P 2 time control 0.10000000149012
ControlName  P 3 amp control 0.10000000149012
   O audio Out out 2

// ^^ oh, there it is

That is… it is possible that, at some point in the past (could even be weeks ago), you might have run an example from some online tutorial that created a reverb SynthDef using .store. This would create a file reverb.scsyndef in the SynthDef.synthDefDir. store’s purpose is to create persistent SynthDefs – so, on purpose, the file is not deleted when you quit (or recompile the class library).

Part of the server’s boot process is to read all of the scsyndef files in the default SynthDef directory. If there is reverb.scsyndef, then this SynthDef would be available in the server, without you doing anything in this session to put it there – Synth(\boop); // sound + no error in my demo.

It is a little bit confusing that the SynthDescLib does not, by default, read in scsyndef files upon language startup. So you would not see reverb in the list at first.

Based on the behavior you are reporting, however, I wouldn’t be surprised if “reverb” appeared in the SynthDescLib after doing

In general, SC’s documentation and built-in examples use add, because (IMO) it’s a bit rude to leave persistent files on disk without warning to the user. But the SC package doesn’t have any control over independently-written tutorials or examples. So there is a possible path from “oh this example looks cool, let me try it” to the current condition of a mystery SynthDef – at the time of trying it, of course, you would have no way to anticipate the longer-term impact, and then when you discover that impact, it would be very hard to think back to that specific example.


This is perhaps not the right diagnosis.

If there is a synth in the server, with a positive node ID, then you can always call set on it. Always.

But you then have to provide control names that actually exist in the SynthDef. In the current case, this is tricky because we have no information about how the SynthDef was built :wink: Guesswork is unlikely to be successful… leading to the conclusion that set is broken for this synth… it’s not… the problem is that we don’t know the language that this SynthDef expects to receive.


I am looking into all supercollider folders in windows explorer and perhaps this one is responsible for the automatic loading of the rreverb ?
And yes indeed it is , there is synthdef called scansynth41 , without loading the synthdef in SC and just creating Synth(\scansynth41) …triggers it
How did those synthdefs end up in that folder ?


Well, the date on reverb.scsyndef is September 2020. Do you remember what you were doing with SuperCollider two years ago?

If not, then you might never know.


Around that time I started with sc ( held on for a few months )
Made two thing on that day , not one featuring a reverb

I save all my sc files on a separate disk ,
,can I savely remove those Synthdefs ?

All I’m saying is that it didn’t make itself.

All it would have taken is one block of code, run one time, with store for a reverb synth. It might even have been buried in the middle of a code block, so you might not have noticed. In any case, this is the kind of thing that’s very easy to forget a couple of years out, so I still think the most likely explanation is that you were running something from a tutorial, and it created this file, and you didn’t spot it until now.

It’s really not a big deal, though. If you don’t need those SynthDefs, just delete them.


1 Like