~ wrms v2 ~~

~ wrms ~~

dual stereo time-wigglers / echo loopers

two time-travel wrms for loops, delays, & everything in-between



  • norns (update 210607 or later)
  • audio input


head to norns.local + click on the books, tab over to available, then scroll way down to wrms & click install

(those updading from v1 may need to remove & reinstall)



  • various timing & click fixes
  • f page for filter controls (previously available as a mod)
  • start & endpoint adjustment for wrm 2 @DuellingAnts (s page alt)
  • wrm 1 can be a pedal looper (hold rec to sleep)
  • wrm 2 can be (more of a) delay (increase e from 0 when asleep)
  • improved share mode (now wrm 2’s buffer control).
    • wrm 1 now auto-adjusts to the length of wrm 2 when switching, which makes poly looping more accessible
  • new share mode wrm 2 → wrm 1
    • in this share mode wrm 2 loops back the delay material at a different pitch/direction in the style of alliterate
  • small delay length abilities @claasp
    • length of wrm 1 can now be adjusted down to .1 milliseconds, just keep turning E2 to the left slowly
    • this is super super fun and there are tons of sweet spots down in the small lengths, especially when combined with ping-pong, feedback filters, octave shifting, and wiggle. you can get into all kinds of pseudo-reverb/chorus, phasor/pitch-shifter/mystery/horrible oscillator territories.
    • I’ve had a lot of fun with it while testing!
  • K1-accessible alt page per-screen, with a gaggle of new controls
    • (from docs):
      • sk: skew the length of each loop channel in the stereo spectrum. great for stereofying mono sources.
      • res: trigger playhead from 0. this is most useful as a mapping destination for crow triggers, which allows for synced delays in a modular context
      • ph: set the phase separation of loop playback in the stereo spectrum.
      • tap: a tap tempo control for delay or loop lengths
      • wgrt: rate of the wgl LFO
      • tp: semitone pitch transposition, also useful as a wide-range pitch bend
      • pan: sets the input pan for each wrm. K2 on this screen sets the overdub mode for wrm 1 - in the default ping-pong mode, panning a mono source will bring in the the stereo ping-pong effect.
      • aliasing: toggling on will disable anti-aliasing for both record heads. the effect is most noticible when recording at lower rates, especially when bent & wiggled.
  • crow input mapping (via @21echo’s crowify)
    • I haven’t been able to test this yet, so lemme know how it goes ! !
  • wrms/lite template
    • this is a simplified alt template for wrms based on how my partner uses it. might be a nice starting point for new travelers ! selectable from the SELECT menu
  • fixes
    • visual lag (?)
    • softcut crashes
  • reverse rate (k2+k3)
  • persistence
  • params
    • input mixer
    • param per control for midi mapping
    • file read
    • voice panning
  • wrms mods / internal architecture restructure
  • auto-generated params from controls
  • session persistence
  • screen lag fixes

(beep boop PRing community catalog) - download + transfer from github if yr giddy

it is in - v fast


Cannot wait to try this! Documentation 10/10!


i don’t have norns but this is so gorgeous mister andrew. mad inspiring. :dark_sunglasses: :sunglasses: :dark_sunglasses:

1 Like

Can’t wait to give this a spin!


you get a medal for first animated norns interface gif!!!


with an lfo + some clever keyboard & midi mappings you could get most of this on a couple ekphras’s :sunglasses:

though a norns is at least a little more easily acquired these days


no joke it took me around 3 hours of messing with imagemagik and other comand line tools to get this working 🤦

it is pretty cool tho


i kid you not @dude
ekphras and all other max/msp-based softcut apps are extremely underrated entry point to this style if you dont have norns

just my own quirk but i been using ableton + ekphras the past few months as much or more than norns samplers/loopers


i also really need some one to kick me to do the next update for that

it could reallllllly use its own version of share


oh low-key @Justmat there’s a modified version of hnds in there running wgl

thanks for that !


oh man, @andrew, so many good wriggle alcoves. wrm sharing is superbly weird and wonderful. congrats on a really wild + 10000% fun script release!!


This is awesome! I noticed one bug though, when repeatedly pressing K3 on the S section, there’s eventually a really short high-pitched sound coming out after which all audio input is dead and Norns had to be rebooted to get audio inputs working (even changing to a different app didn’t help). I tested and managed to freeze it three times.


I ran in to this as well. Another thing I noticed was control input lag when the wiggles were heavily modulated. I suppose in some ways it is better that control input is delayed rather than dropped so that you can still navigate back to the menu and reboot norns if that problem arises.

Very fun script though! Once again got distracted playing when I meant to work on studies. :grin: I promise that I’ll contribute more than “hey I found a weird thing” at some point.

did you pitch up, like, many times ? there’s an upper limit that will crash softcut. i can put a limit on the value but i need to test what that limit is

@coreyr are you on vanilla norns ? i think this might be a cpu load issue - i haven’t run into it on my shield but i believe i have more cpu. had one other person with vanilla run into it. i think if i decrease the softcut poll rate that’ll help mitigate this

I am on a 3b+ fates on the most recent forked norns image. I was pushing really hard, recording to both buffers and doubling/halving the rate back and forth rapidly. It was outside of my likely use case, but I like to see what the boundaries of useful parameter mangling are with new effects.

1 Like

BTW I ran into a similar issue with the upper bound (in my case I was trying to use softcut rate to create oscillators) - here was the response


the rate limit is +/- 64. rate setters should be clamping but i’ll check
[hm, seems that they’re not, so i will add that.]

softcut poll rate

yeah, phase polling quantum isimportant to keep in mind to limit the amount of OSC traffic generated. (rate / quantum) is poll update speed basically. if this is crazy high, it could lock up the UI; it shouldn’t crash the audio.


yea I have polling fast (= 0.01s) essentially because I’m using the position from the poll to set loop_end in the loop-pedal punch in style. so in this particular case poll rate = loop accuracy. the thing that might truly be slowing it down though is also slapping redraw() into that poll which definitely would be better off in a slower metro. that’s what I was going to try next

definitely decouple your redraw from the other stuff as a first step. probably a good rule of thumb is to always have redraw running from a dedicated metro.

and my gut reaction is that the described use of the phase poll is not a robust or efficient architecture for the feature.

if rate isn’t being modulated as loop is set, just measure time since setting loop, and multiply rate, no need to involve the backend.

for when rate is being modulated as loop is set, i think we should probably add something to the backend to make this a realistic goal. i see two options:

  • add commands to immediately set loop endpoints to current (unquantized) phase position
  • build out a little more support for polling options, particularly the poll/update command which gives you a single value immediately.

both are simple, but it’s monday and i’m doing day job stuff for a while.

oh but, [update] since you say 0.01s, that should be fine. but if you’re talking about the phase quantum, then remember that you need to multiply rate to get actual update speed. so if rate = 10x then you’re in trouble. that’s what i mean by “not robust.”