a wet/dry control would be a good solution

1 Like

I have a few script updates in my “queue”. I just gotta make the time to “do the damn thing” :sweat_smile:

I am hoping to get around to things this week :crossed_fingers:


all the hard work is much appreciated!

1 Like

also pinging @Justmat

that’s pretty bizarre.

the error message occurs when C layer gets an OSC message for a poll that isn’t recognized by the lua layer. i’ve never seen the error actually happen since the poll module was developed. Poll.polls is cleared and populated only once, when an engine is loaded.

Glut engine is one of relatively few that uses polls implemented in supercollider. if we can make a minimal repro case i can get to the bottom of it. (not a bad time to do that since we are looking at substantial architecture changes to SC environment anyway.)

some brainstorming:

one possiblity is a race condition at some level. here i should explain something very important about script lifecycle (don’t we have a tutorial? ehh): script init function will execute under very specific conditions: if an engine is requested by the script, it will have already been loaded, ready to receive commands, with all polls and command tables populated and ready to roll. we could have a bug in lua or in matron/weaver that violates this guarantee.

another thing to consider is that poll.polls is just a field in a global table - it is not protected from corruption by scripts.

we could probably also arrange a more graceful failure mode, but that is not a real fix. as it is, if the warning is issues every few milliseconds over a websocket then yes that will clog and hang both the norns UI and the web client.

1 Like

Hey all. I’ve noticed some clipping-type distortion when using Mangl that seems tied to the density parameter, like when the density is too high the internal headroom is being a exceeded. I’ve noticed that it’s prevalent even if I turn the sample volume and main output (and headphone) volume way down. The only way it seems to go away is by reducing the density. I’ve tried this with a variety of samples. Is it possible that the audio bus of the supercollider engine is being clipped? Wouldn’t turning down the sample volume reduce that?

Has anyone else experienced this?

I’ve experienced some clipping too, but reducing volumes seems to help, along with adjusting my compression settings and delay sends.

@Justmat when did you add the LFOs!?! Did I just not scroll down far enough before? Hahaha. They’re great!!! I need to look at the destination targets when I have some better brain space to see if I can add pitch…

1 Like

Ah yes thanks, I forgot to mention that I made sure the reverb and compression were turned off and the delay send was set to 0.

I’ve run into this when using an LFO to modulate density (I think it was density anyway). My fix was to lower the depth of the LFO and play with the offset until I found a good compromise.

there are at least two relevant parameters, density (call it D) and size (call it S).

D is expressed in Hz, it is the rate of new grain triggers.
S is expressed in seconds, it is the length of each grain.

neither are randomized (i’d consider randomizing the trigger impulse train!), so the number of overlapping grains is always ceil(D*S).

so if e.g. size is 1 and density is 8 then yes, you should allow an extra linear gain of 8.0 = 18db of headroom. (maybe that counts as “way down” for you, maybe not, i dunno.)

this seems like a case where, or similar would help at the end of the chain in the synthdef. and/or, the synth itself could attenuate by (ceil(S*D)), though this may not always be desirable.

i don’t believe we explicitly clip the engine output, and neither does the JACK transport, but i could be wrong about the latter especially.


Thanks for the detailed response @zebra!

I’m not sure how I went this long without making this change :sweat_smile:

I will look into limiting/softclipping in the synthdef, while making the impulse changes :slight_smile:


Thanks for the explanation @zebra. And thanks for bring willing to look into it @Justmat!

I was hearing the clipping with the sample at -60 at times just fyi.
Thanks again!

PS: Out of totally curiosity @zebra is the Supercollider engine in Norns operating at 32bit floating point? I’d expect it to because that’s how it works on desktop as far as I know. If it is I’d be surprised that it needs a limiter/clipper at all.

Completely slipped my mind, but there is already a delay send parameter per voice! Set these to 0 if you don’t want any wet signal :slight_smile:

1 Like
  1. i said additional headroom. factor in stuff like the delay send levels and &c &c &c
  2. i picked some arbitrary numbers for illustration, i don’t know what your settings are. maybe the density is set to 100hz and the size is set to 10 seconds.
  3. but yes, 60db is 1000x so that’s rather a lot. so i don’t know if what you’re hearing is actually “clipping.” high grain density can also cause dropouts from excessive CPU usage.

yes, the audio busses in SC are floating point. audio out of norns still can’t exceed unity at end of chain. and like i said, there are other places where clipping could happen (JACK.) i checked and we’re not explicitly clipping anywhere else in the crone chain except when recording to disk. (and internally in softcut)

Thanks for the info! It does sound like clipping vs dropouts but maybe you’re right. I could record some if that would be helpful. Let me know

This makes me think I should adjust the limits on parameter ranges. Pretty sure that I’ve just used whatever angl was using at the time of forking, and not really thought much about it.

i should do my homework and clarify that (assuming i understand the code correctly) the actual ranges are specified here and the LFOs cannot push beyond those ranges:

so size goes up to 0.5s and density goes to 512Hz. that’s potentially ~48dB of gain from grain overlap. i don’t know how much gain the delay fx can add on top.

with those ranges i’d definitely consider programmatically attenuating the grain output at least at higher levels of (size*density.)

sure; should be easy to diagnose from a recording. if you record internally with TAPE there will be final clipping at unity before writing to a 24b wav.


haha, i just pulled and saw the change from to on master :slight_smile:

if you don’t mind some more unsolicited advice, i think i would add a parameter or two to control the amount of randomnesss, something vaguely like

arg density_rand_amt;
var density_rand, density_mod;
density_rand =;
// cheap way:
density_mod = density * (1 + (density_rand * density_rand_amt));
// but even better for controlling the extent of randomized grain rate:
density_mod = density * (2**(trig_rand * trig_rand_amt));
grain_trig =;

because sometimes you do want a totally periodic grain series.


Ah! That makes sense. Please, feel free to give as much advice as you’d like! My knowledge of coding is pretty much limited to Teletype and Norns :sweat_smile: so… there is much to learn :slight_smile:

edit: expect an update soon-ish :smiley:


I recorded a quick clip below @zebra / @Justmat .

The settings are SIZE: 140, DENSITY: 20, so almost default.
I recorded directly to the Norns and I played around with the sample volume during the recording. The weird thing, as you’ll hear, is that the distortion doesn’t change much with volume as far as I can tell. It makes me think the signal is getting clipped before the volume parameter.

The original recording does not have clipping in it. I can post that if needed.
Anyway, thanks and I hope this is somewhat helpful.

Had this happen just now! I was making changes to the engine, and when I issued a ;restart maiden was flooded with the norns.poll warning. Everything seems pretty locked up now.

@zebra, steps to reproduce.
have mangl running.
open maiden.
issue ;restart in the matron repl.

At this point the repl is flooded with warning: norns.poll callback couldn't find poll and things get sluggish.

1 Like