One thought - just out loud, because I’m newish to norns - I’m finding mapping control to a 16n works surprisingly well, even though they’re not relative.

How hard, do you think, would adjusting code to say have a set of ‘macro’ parameters be? I ask because what I’d quite like is, arc-style, to map parameters to some faders, and just have them effect the current channel. Possibly with soft-pickup. These would be different to the others, but it mimics the arc-style programming quite well.

I am probably competent enough to write this, but before I dive in, wondered if there was an obvious blocker?

having parameters that affect multiple other parameters seems pretty straight forward, and there are variables for current channel, so that part should be pretty simple. soft-pickup would take a little thought. :sweat_smile:

edit: for macro param example

-- make a function that updates multiple params, use division to set sensitivity 
local function macro_control( chan, v)
  params:set(chan .. "this_param", v)
  params:set(chan .. "other_param", v / 2)

-- make a param that calls the macro_control function
params:add_control("macro", "macro",, 1, "lin", .01, 0))
params:set_action("macro", function(v) macro_control(current_chan, v) end)
1 Like

gotcha. yes, I wasn’t asking you to implement soft pickup. I might play with this!

1 Like

Hey hey! Had a lockup this morning while using Mangl. Up to date on everything, running factory norns and grid. Loaded yesterday’s session. Audio was playing, but norns was sluggish/unresponsive. Matron wasn’t reading out until I issued the ole ;restart. Then, it spit out a super long list of warning: norns.poll callback couldn't find poll. I didn’t get the full readout, bc safari actually beachballed on me. After ;restart I had a SUPERCOLLIDER FAIL and norns would not recognize K1-K3 presses. Safari still beachballing. All the while, the same samples from my mangl session were coming through in Ableton; norns didn’t stop playing audio until I finally hit the kill switch on the bottom. I know this is of limited help without the full matron readout; I promise I tried :laughing:

EDIT: Also worth mentioing that I was able to check CPU usage, and it was up near 80%. The same mangl session (which is working flawlessly now) is currently using 28%.

Apologies for the troubles! I’m not sure what causes this, but I have experienced that warning message. :dizzy_face: I’ll spend some time trying to reproduce it this weekend.

Oh no sweat, and it is working flawlessly now. Just wanted to report back!

1 Like

lovely script…wondering is there a global reverb on mangl? didn’t notice one in the params but wondering if it’s possible to turn it off?

It could be turned on in your system wide audio settings.

1 Like

Mangl doesn’t have a “global” reverb, but norns does. Navigate to SYSTEM - AUDIO on norns, and you’ll find reverb and compressor settings.

hey thanks i’m aware of the global reverb on norns… it might just be the delay in the script that’s creating the affectation or possibly the sample itself. i’ll dig deeper!

1 Like

I should probably add wet/dry controls for the delay. The delay used in mangl can be pretty verb-y sounding.


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.


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.