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:
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
Dust.kr on master
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.
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 so… there is much to learn
edit: expect an update soon-ish
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.
;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.
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.
yeah i just checked to confirm.
SYSTEM > RESET does what is probably wanted: a soft reboot of the entire norns stack by means of
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)
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
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.
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?
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.
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.
This is likely a general Norns thing. All the midi mapping is handled by the parameter menu.
moving it to NORNS help.
so the MIDI controller issue was resolved here:
(i tested it with a horde of controllers)
the killer was…
(cue suspense music: duhn, duhn, DUHN!)
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)
@SPIKE, i just changed the screen drawing to make the volume/cutoff indication persistent on the screen. I almost forgot
THANK YOU THANK YOU!!!
so much noiz to create during the Plague!