#222

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:

3 Likes
#223

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.

#224

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
#225
  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)

#226

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

#227

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.

#228

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.

2 Likes
#229

haha, i just pulled and saw the change from Impulse.kr to Dust.kr 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 = LFNoise1.kr(density);
// 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 = Impulse.kr(density_mod);

because sometimes you do want a totally periodic grain series.

5 Likes
#230

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:

2 Likes
#231

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.

#232

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
#233

Ok, nobody told me this happens after ;restart. It makes perfect sense. The matron process has been forcibly killed and relaunched, supercollider has no idea and continues to send updates that the new matron process has no idea how to handle because it never launched the engine.

I’m not sure that we really should “fix” this - having matron ;restart perform needed steps for a clean shutdown of the system - that’s not really its function, it’s a low level development feature. Better to use SYSTEM > RESET, and maybe we should add an equivalent repl command or something.

for now, you could issue ;restart in sclang REPL, then in matron REPL, and i think that would work (possibly with a loss of application state) but it’s probably better to use RESET on the device.

1 Like
#235

yeah i just checked to confirm. SYSTEM > RESET does what is probably wanted: a soft reboot of the entire norns stack by means of systemd.

looking at this made me realize that there could be better docs and maybe some functional cleanup around process lifecycle management on norns. i’ll open this on GH instead of further derailing this thread. (https://github.com/monome/norns/issues/1014)

1 Like
#236

In case it’s helpful- the couple of times this has happened to my norns while running Mangl, the buttons and encoders were unresponsive, which is why I turned to the ;restart command.

#237

that makes sense. but i don’t think we have determined what the actual problem is yet. so far the only repro case i’ve seen requires issuing ;restart in matron repl, after launching the engine, which is a “won’t fix” issue for me at present. (that is actaully expected behavior; it’s not nice, but matron ;restart is rude and should only be used for diagnosis of startup problems in the norns lua/C stack.)

you’ve observed the flood of poll errors to happen “out of the blue”, from normal operation? after loading the script/engine? sporadically after restart? when plugging/unplugging controllers? &c. i have been trying to reproduce today but so far no luck. (i onle have a grid, and have been replugging it a lot.) and if this happening, it’s probably not the fault of the script but something that needs to be addressed at system level.

1 Like
#238

@Justmat
hello again!

another couple of performance requests…
(please forgive me if these are not possible and or have been already requested)

  • is it possible to have the volume level for each sound persistent on their screens? and if so…can they change with external control as well as with E1?

  • is it possible to add a parameter to turn off the screensaver/sleep screen mode?

thank you!

1 Like
#239

I’ll consider making the volume persistent before I release the next update. I don’t think I can do anything about the screensaver from the script, but I could be wrong. I’ll investigate.

1 Like
#240

The most crippling instance occurred when loading a saved session (a preset, from the menu where one can assign midi CC’s, etc). Like yourself, I am arcless, so that variable is out for my setup. Otherwise, vanilla 128 grid (2019) and vanilla norns (also 2019).

Norns only returned to a normal state after I pulled the plug via the kill switch on the bottom.

FWIW, this has only happened 2-3 times, out of probably 30 sessions.

Part of the difficulty here is that, when this flavor of lockup occurs, maiden/matron don’t produce a readout. Is there any kind of log file that one can pull after the fact? Sorry for my ignorance, I’m trying to be helpful, but alas am a level three minstrel.

1 Like
#242

This is likely a general Norns thing. All the midi mapping is handled by the parameter menu.

1 Like
#243

ok…
moving it to NORNS help.

thanks!

1 Like