#12

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

15 Likes
#13

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.

2 Likes
#14

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.

#15

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

#16

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
#17

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

4 Likes
#18

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.

2 Likes
#19

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

#20

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

#21

the other thing i should say about setting high rates is that i just wouldn’t do it if you don’t have to, particularly while writing, because it’s just expensive. if rate is, say, 63.9, then each sample of processing will require 63 or 64 interpolated writes to the buffer, and these are the costliest operation.

since you only have 2 voices you should be ok pushing the envelope of performance, but in general i’d limit rate modulation to 3 or 4 octaves to avoid dropouts. (not crashes.)

the crashes are almost certainly from exceeding the hard limit on rate, which will smash memory since we have traded some safeguards for speed in the inner read/write loops.

#22

during initial dev I was thinking about either of these being great to have ! rate is being modulated in my case, otherwise util.time() is super easy. no rush at all, bc I think if I clean up my redraws the current method will be plenty fine for this app. (redraw in poll was total laziness on my end to poop this app out quickly)

& yes definitely next update I’ll head in and limit rate so nobody is crashing things. I haven’t even noticed the performance drops at high rates outside of the full crash though which is honestly a testament to how robust everything is

#23

for the record, when i work on softcut my target is usually to have good CPU headroom (>50%) with all voices reading and writing simultaneously at +/- 8x speed. chose to make the rate limit bigger because why not (just don’t use that for all voices at once) but it does need a caveat.

i’ll push a change on the backend, maybe such that setting loop point to -1 indicates “set to current position,” and also limit the rate there of course. (but clamping the rate on backend will happen silently from perspective of script.)

2 Likes
#24

thank you for the worms , they are really sweet :slight_smile:

3 Likes
#25

thank you !! wld love hear what everyone is making :eyes:

many more wrms coming soon ~~

2 Likes
#26

here is some no input wrms! Wanted to try this script but was at the gym with no inputs avail.

enjoy (careful it’s loud!)

9 Likes
#27

This is one of the few times someone would be excited to hear that there’s wrms at a gym! :laughing:

2 Likes
#28

this is bonkers @vcvcvc_val ! !

just pushed a quick update. probably didn’t break anything

1.0.1

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

fixed the super annoying loss of settings btw sessions and added a bit of midi control options via params - rec should work with footswitches ! also cleaned up my redraws to address the weird screen lag stuff - if anyone gets that again be sure to let me know + maybe share yr cpu % ?

been putting lots of energy into revamping the guts for * wrms mods * via a new softcut lib, stay tuned !

10 Likes
#29

version 1.1 is here !!

  • 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 *

*

Screen Shot 2020-02-20 at 6.30.56 PM
Screen Shot 2020-02-20 at 6.30.56 PM1646×1234 322 KB

with this version I invite you to check out -> * the guts *

(a script is an interface, after all)

i’ve put a lot of thought into the internal structure of wrms and it is now ripe for redefinition via modification or the integration into other norns projects as a softcut controller

to help illustrate this I’m going to be posting some wrms mods of my own but my hope is that others may choose to do the same ! a looper is very personal and I’m hoping you and wrms might be able to change && grow together

filt ~~

wrms_filt.lua (4.0 KB)

1st wrms mod is a very simple addition that I decided to leave out of the main release. It adds a filter to the feedback path of wrm 1 - very great for dark analog-delay tails in lowpass mode but also for other things when wrm 1 is looping

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

! read the guts for more info !

20 Likes
#30

this is so dope and such a cool gift to folks wanting to extend the capabilities of their synth-based scripts. super stoked on (and grateful for) this release and your work, @andrew!!

2 Likes
#31

thank you for footswitch support! that’s awesome! :grin:

1 Like