~ wrms ~~

[andrew]

wrms

dual asyncronous time-wigglers / echo loopers

a remix of cranes by @dan_derks

requirements

a norns !

download

head to norns.local + click on the books
tab ovr to available & refresh community catalog

documentation

basics

two wrms (stereo loops), similar in function but each with thier own quirks + abilities

E1 up top changes which page is displayed. pages contain controls, mapped to norns’ lower keys and encoders. the location of the control dictates which wrm will b affected.

v o b s >

let’s start with page v, ok ?

generally, rec decides whether new time is gobbled. notice at load, wrm1 is echoing via continuously gobbling new time and fading old time. wrm2 however, is dead asleep. wake her up by toggling record once, and then again. the length of her orbit is detirmined by the time between these initial toggles - after which gobble toggling returns to normal. to go back to sleep, hold rec, and begin again. (wrm2 mimics many of yr fav loop pedals). notice that wrm1 feeds into wrm2. we’ll get back to this later.

oh, and vol controls the volumes

page o is for the past.

old decides how loud the past is, && how long it resonates. use old to alter wrm1's echo chain, or fade wrm2's past to make room for the future. with a high old, wrm1 can be used more like a looper. likewise, a low old on a shorter wrm2 will sound an echo.

b wiggles time

bnd is the most tactile example. bend wrm1 between single and double time rate as she approaches light speed. wrm2 has more flexibility - << and >> halve and double time, hapily gliding between while you hold and release.

a technicality

(the rate of time is inversely proportional to orbital altitude)

wgl scales time-varying orbits for both wrms - a low value makes a nice wobbly sound, very low adds subtle character. a high wiggle will start to pass through the singularity, but i’ll let you decide whether that’s an issue :~)

s affects wrm1 alone

finally, here, we can make wrm1 longer using l (which admittedly just looks like a vertical line, lol). with s we can scoot wrm for subtle delay fizzles or sub-loop glitchy stuff. << and >> repeat actions from the previous page to wrm1, useful for dual phase-orbiting looping configurations.

> communicates

remember how wrm1 feeds into wrm2 ? we can change that with > and <. feel free to place your delay after the loop for an alternate workflow, or feed both wrms to each other for more suprising results.

feed a stereo panned field to wrm1 to hear the effect of pp - it reverses old on each pass for a ping-pong effect

lastly - share creates a new instrument. toggle a shared past and memory (/ buffer region) for both wrms + telepathic time loop conversations. obviously this unlocks new feaures underneath every other control, but i won’t spoil them !

extending

wrms is both a script and a library

all of the functionality (apart from UI) is contained in functions inside a single lua table, which means an external script can easily include wrms to alter, customize, fine-tune, or enhance its behavior. the wrms mods below are illustrations of this process - both the mod files and the main script are heavily commented to help a new programmer understand what is going on. it should be a great jumping off point after reading norns studies !

mods

to use, just pop the file into dust/code ! it’ll need main wrms installed to operate

wrms_filt.lua (4.0 KB)
adds filter into the feedback path of wrm 1

wrmsmsh.lua (368 Bytes)
msh > wrms (need both scripts)

changelog

1.0.1

• auto-generated params from controls
• session persistence
• screen lag fixes

1.1.0

• 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

roadmap

2.0 ?

• K1 alt menu with pattern record + presets per page
• Long Egg mode
• will turn YOU into a wrm

andr-ew/wrms

[andrew]

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

it is in - v fast

[noiserock]

Cannot wait to try this! Documentation 10/10!

[dude]

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

[Justmat]

Can’t wait to give this a spin!

[tehn]

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

[andrew]

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

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

[andrew]

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

[glia]

@andrew

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

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

[andrew]

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

[andrew]

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

thanks for that !

[dan_derks]

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

[bereenondo]

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.

[coreyr]

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. I promise that I’ll contribute more than “hey I found a weird thing” at some point.

[andrew]

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

[coreyr]

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.

[crim]

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

Norns: ideas

you should be able to make quite stable oscillators just with loop length, which has no lower bound. rate modulation has a hard upper bound. (== available history in interpolation window) which is 64.

[zebra]

@andrew

i need to test what that limit is

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.

[andrew]

@zebra

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

[zebra]

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.”