Hi,
I am relatively new to Supercollider and have been working on a project for some weeks now which is nearing completion. However I am repeatedly coming up against a situation where, after initialising the program the synths I am using fail to sound (70% of the time) although the data used to supply them continues to be processed as I can see in the post window. If I stop the program and try a reboot I get: FAILURE IN SERVER /s_new Group 1 not found. If I wait a bit longer FAILURE IN SERVER /s_new too many nodes is generated repeatedly. Using plotTree I note that synths are being created but not sounding. I wondered whether this situation had anything to do with problems in clientID assignment?- though am not sure. I am keen to finish the project asap so any suggestions as to a possible solution would be very welcome. Thx in advance…
Hi,
more specificactions would help. You are providing no code and nearly no other information what you are actually doing, so it’s difficult. The message indicates that some language process is continously running after server has been quit (Task, Routine, Pattern/EventStreamPlayer ?). Seems you couldn’t really stop your process for whatever reason.
Hi again,
Thanks for giving my question your attention. Here is the code. It works as desired in about 50% of cases. But as indicated in my question I get "FAILURE IN SERVER group 1 not found in a significant number of start-ups a situation which is unacceptable for performance obviously. Interestingly I also get this message on first start up which suggests that it is not simply a question of a previous pass failing to terminate, The situation has been slightly improved by assigning source and effects groups directly but the problem has not been alleviated entirely. Still trying to master posting code to this forum being a newbie…
(
o = Server.local.options;
o.memSize = 2.pow(20);
s.reboot;
Server.default.waitForBoot {
SynthDef("Main",{
|out = 0, freq = 440, dur = 0.1, pan = 0, rtAdd = 0, amp, frictionFreq, frictionMix,envLevel,
noiseFreq, frictionQuality = 0.01, dA= 0|
var sig, dkFreqs, lfn, dkAmps, dkRingTimes, exEnv1, exEnv2, exFriction1, exFriction2, chExFriction, exciter1, exciter2, comp_sig;
exFriction2 = HPF.ar(SinOsc.ar(frictionFreq) + WhiteNoise.ar() +
[LFDNoise3.kr(noiseFreq), LFNoise0.kr(noiseFreq), LFClipNoise(noiseFreq)].choose, 100, 0.5);
(More code here..............)
)
I have posted code in the hope that you kind find the time to look at it. Thx,
This is a quite large amount of code and it seems to contain private classes too, so the error is not reproducable, in general it’s recommended to post a clear reproducer as otherwise it’s rather unlikely that people spend time with your problem - but I see that this is difficult in this case.
So all I can do is mentioning some points that I’m noticing:
-
You are using interpreter variables at several occasions (f, m, d, q, x - or did I overlook variable definitions ?). In such a large piece of code that’s potentially dangerous.
-
What looks especially critical to me is that you are building an array of Routines { … } ! cbsize and they all seem to use the same interpreter variables, this looks insane. Does the problem occur with cbsize == 1 ? This check could pinpoint it.
-
You could use trace to check your Pbinds or at least certain of their streams. What about \dur d ? Small or zero durations are a frequent source of errors. You could check with the scheme below.
{
|i|
var d = rrand(0.5, 2);
Pbind(\midinote, 50 + (5 * i), \dur, Pfunc { d }.trace(prefix: "dur_" ++ i.asString ++ " ")).play
} ! 7
)
- In general I’d try to modularize the code into smaller pieces. This makes debugging much easier and helps to look through the code when you come back to it after a while.
Hope that helps a bit.
Thx for your helpful; suggestions. Re interpreter variables I (mistakenly?) took them to be confined to the scope of the routine they occur in; that aside, I agree that reusing variables doesn’t help debugging. I must say I’m a bit disappointed with Supercolliders’ debugging facility. In my own case complexity has come back to haunt me!.
PS. In addition and in consequence of your reference to interpreter variables I’ve spotted coding errors in the SynthDefs.
Correcting these and changing variable names has made made a considerable difference to the sonic result (to my amazement I have to say !)
If you don’t declare the variables, they will be global in scope (this is not entirely correct, but for current intents and purposes…)
You can easily rectify this by declaring them with a var statement at the top of your routines, thus rendering them local in scope.
Cheers
eddi
Agreed, this is a weak feature of SC that developers are aware of, it was also confirmed by the recent user survey. A step debugger in the language would be nice, but that would take time to add.
Meanwhile we have to live with the current state, but even with limited tools you can make debugging life easier. E.g. polling as server snooping can be done with labels, you can take lower rates to avoid cluttering the post window. Tracing whole event streams (Pbind(…).trace.play) is also fine.
Just in case you haven’t found these files elready
http://doc.sccode.org/Guides/Tracing-Processes.html
http://doc.sccode.org/Guides/Debugging-tips.html
“FAILURE IN SERVER” is only when creating synths or groups. So, for testing purposes, you could delete everything else temporarily (and supply dummy data for synth args).
hjh
Searched hi and lo for the cause of this problem over 5 days. Stripped everything down as suggested by DkMayer and jamshark70. Felt like a tedious thing to have to do. Then found the source of the issue within five minutes. Problem lies in the Synthdef statement:
[LFDNoise3.kr(noiseFreq), LFNoise0.kr(noiseFreq), LFClipNoise(noiseFreq)].choose. Stumped if I know why this caused synth not to register in the group… Just glad to have solved issue. Thx to you guys who helped… Could have saved myself five days of frustration . A lesson well learned on my part… !
The LFNoise variants can cause problems with very high and very low frequencies, see the LFDx help files for an explanation. In general, if applications are not CPU-critical, it’s a good idea to always take the LFD variants. From this array the coice is done at SynthDef build time. So the 70 % rate of problems could confirm this source of trouble …
It’s actually a documentation issue that the possible problem is described only in an indirect way in the LFNoise help files:
Generates random values at a rate given by the nearest integer division of the sample rate by the freq argument.
… where it is described directly in the LFDNoise help files (footnote). Actually it should be the other way round: the warning should be there where the trouble can happen, it’s not that relevant where it doesn’t happen …
Thx I will read the documentation you refer to. Interestingly, as a result of trying to find a different solution towards the same effect I note that If:
exFriction = HPF.ar(SinOsc.ar(frictionFreq) + WhiteNoise.ar() +
[LFDNoise3.kr(noiseFreq), LFNoise0.kr(noiseFreq), LFClipNoise(noiseFreq)].choose, 100, 0.5);
is recoded as:
lfn = [LFDNoise3, LFNoise0, LFClipNoise].choose;
exFriction = HPF.ar(SinOsc.ar(frictionFreq)+ WhiteNoise.ar() +
lfn.kr(noiseFreq), 100, 0.5);
The issue is resolved. Which in addition to what you mention, would seem to indicate that, in the original, it is the act of assignment of the (same?) frequency argument to the noise Ugens whilst simultaneously making a selection that is problematic. If the frequency argument is assigned subsequent to selection then the problem does not occur.
Yes, this makes a slight difference.
In case (a) all three LF ugens will run in the synth although only one is chosen at build time for further calculation.
In case (b) only one (also chosen at build time) will be running.
You can see the difference in the ugen graph scheme of isolated examples:
{
arg noiseFreq;
var lfn = [LFDNoise3, LFNoise0, LFClipNoise].choose;
SinOsc.ar(100, 0, lfn.kr(noiseFreq))
}.asSynthDef.dumpUGens
{
arg noiseFreq;
var lfn = [LFDNoise3.kr(noiseFreq), LFNoise0.kr(noiseFreq), LFClipNoise.kr(noiseFreq)].choose;
SinOsc.ar(100, 0, lfn)
}.asSynthDef.dumpUGens
So it’s not the kind of assignment itself which causes the trouble but the consequence of the parallel LF ugens (maybe the lacking default of noiseFreq, so it defaults to 0, which is bad for LF ugens)
However, it might be worth rethinking your SynthDefs. The solution with choose is always a random choice at compile time. Consider the use of Select, then you can do the choosing at runtime with a type parameter, also from Pbind (slightly more CPU-intense though).
… oops I mixed up the order - the second example is the one in which all three ugens are running !
Would you mind posting the reduced example that reproduces the error?
It’s very odd that a SynthDef’s construction would cause a group to be unavailable.
I have a feeling there might be a subtle bug here. I’m curious. Don’t have a lot of time at the moment but I can’t explain why that specific change to your SynthDef would cause that specific error to disappear.
hjh
The OP is missing a .kr on the LFClipNoise
Thx alln4ural. The .kr in the original is indeed missing. Case of not seeing wood for the trees? Testing with:
exFriction = HPF.ar(SinOsc.ar(frictionFreq) + WhiteNoise.ar() + [LFDNoise3(noiseFreq), LFNoise0(noiseFreq), LFClipNoise(noiseFreq)].choose, 100, 0.5)
reproduces the original error in 100% of cases although, curiously, it does compile. Issue closed.
As a final comment: technically I would imagine that:
exFriction = HPF.ar(SinOsc.ar(frictionFreq) + WhiteNoise.ar() + [LFDNoise3.kr(noiseFreq), LFNoise0.kr(noiseFreq), LFClipNoise.kr(noiseFreq)].choose, 100, 0.5);
should produce the same effect as:
lfn = [LFDNoise3, LFNoise0, LFClipNoise].choose; exFriction = HPF.ar(SinOsc.ar(frictionFreq)+ WhiteNoise.ar() + lfn.kr(noiseFreq), 100, 0.5);
Nevertheless, to my ears the effect is quite different. I shall use both!
Oh-kay, right, now I see it. The missing .kr means that the SynthDef is malformed, and that could cause all kinds of error messages that seem unrelated.
to my ears the effect is quite different
I was all set to say this must be in your imagination, but actually there is one possible behavioral difference.
The [a.kr, b.kr, c.kr].choose case produces 3 random-value UGens, and uses the output from one of them. But all 3 are using the random number generator, and changing the RNG’s state (3 times, per noiseFreq period).
The other formulation produces only one of those 3 options – the other two never exist. So, at every noiseFreq interval, there is only one RNG update rather than 3.
It’s actually an interesting question, whether SC should optimize the two unused units out. The SynthDef builder does have logic to do this. My feeling is that *Noise ugens should not be subject to this kind of optimization, because they do change the state of the system.
hjh