Mangl

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.

2 Likes

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

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

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

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

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

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.

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

@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

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

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

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

1 Like

ok…
moving it to NORNS help.

thanks!

1 Like

so the MIDI controller issue was resolved here:
(i tested it with a horde of controllers)
https://llllllll.co/t/norns-mangl-midi-issue/29730

the killer was…



.pmap
(cue suspense music: duhn, duhn, DUHN!)

thank you @zebra , @dan_derks and always @Justmat for his patience!
:slight_smile:

1 Like

update v2.2

Just a quick update to make use of the new param menu features. Make sure you are running the latest version of norns. (200323 at the moment)

edit:
@SPIKE, i just changed the screen drawing to make the volume/cutoff indication persistent on the screen. :smiley: I almost forgot :smiley:

9 Likes

THANK YOU THANK YOU!!!
so much noiz to create during the Plague!

3 Likes

Most welcome! :sweat_smile: :sweat_smile: :sweat_smile:

1 Like