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