Time stretching + Reverb can break an orbit's global effects

[geikha]

Recreating the bug:

Run the following:

d1 $ slow 4 $ striate 32 "bev" # cut 1 # room 1

3 group
            1116 group
               -912 dirt_sample_1_2
                 out: 36 bufnum: 376 sustain: 0.49975594878197 begin: 0.625 end: 0.65625 speed: 1 endSpeed: 1 freq: 261.62557983398 pan: 0 span: 1
               -920 dirt_gate2
                 out: 38 in: 36 sustain: 0.49975594878197 fadeInTime: 0.0010000000474975 fadeTime: 0.0010000000474975 gain: 1 overgain: 0 amp: 0.40000000596046 sample: -1945774592 gateSample: 0 cut: 1 gateCut: 0 cutAllSamples: 0
         1004 dirt_delay2
           dryBus: 38 effectBus: 40 gate: 1 delaytime: 0 delayfeedback: 0 delaySend: 1 delayAmp: 0 lock: 0 cps: 0.63333332538605 resumed: 0
         1003 dirt_reverb2
           dryBus: 38 effectBus: 40 gate: 1 room: 1 size: 0.10000000149012 dry: 0 resumed: 0
         1002 dirt_leslie2
           dryBus: 38 effectBus: 40 gate: 1 leslie: 0.5 lrate: 6.6999998092651 lsize: 0.30000001192093 resumed: 0
         1001 dirt_rms2
           dryBus: 38 effectBus: 40 gate: 1 rmsReplyRate: 0 rmsPeakLag: 0 orbitIndex: 0 resumed: 0
         1000 dirt_monitor2
           dryBus: 38 effectBus: 40 outBus: 0 gate: 1 limitertype: 1 resumed: 0

Now run the following, you'll hear SuperDirt hang for a second and then it'll start working again, with no reverb:

d1 $ slow 4 $ striate 32 "bev" # cut 1 # room 1 # timescale 0.5

3 group
            1285 group
               -3616 dirt_stretchsample_1_2
                 out: 36 bufnum: 376 sustain: 0.24887797236443 begin: 0.90625 end: 0.9375 speed: 1 endSpeed: 1 freq: 261.62557983398 timescale: 0.5 timescalewin: 1 pan: 0 span: 1
               -3624 dirt_gate2
                 out: 38 in: 36 sustain: 0.24887797236443 fadeInTime: 0.0010000000474975 fadeTime: 0.0010000000474975 gain: 1 overgain: 0 amp: 0.40000000596046 sample: -1945774592 gateSample: 0 cut: 1 gateCut: 0 cutAllSamples: 0
         1004 dirt_delay2
           dryBus: 38 effectBus: 40 gate: 1 delaytime: 0 delayfeedback: 0 delaySend: 1 delayAmp: 0 lock: 0 cps: 0.63333332538605 resumed: 0
         1003 dirt_reverb2
           dryBus: 38 effectBus: 40 gate: 1 room: 1 size: 0.10000000149012 dry: 0 resumed: 0
         1002 dirt_leslie2
           dryBus: 38 effectBus: 40 gate: 1 leslie: 0.5 lrate: 6.6999998092651 lsize: 0.30000001192093 resumed: 0
         1001 dirt_rms2
           dryBus: 38 effectBus: 40 gate: 1 rmsReplyRate: 0 rmsPeakLag: 0 orbitIndex: 0 resumed: 0
         1000 dirt_monitor2
           dryBus: 38 effectBus: 40 outBus: 0 gate: 1 limitertype: 1 resumed: 0

Let's try to go back to the old pattern, with the reverb it had. It seems the reverb has died and doesn't work anymore:

d1 $ slow 4 $ striate 32 "bev" # cut 1 # room 1

3 group
            2026 group
               -15472 dirt_sample_1_2
                 out: 36 bufnum: 376 sustain: 0.49975594878197 begin: 0.0625 end: 0.09375 speed: 1 endSpeed: 1 freq: 261.62557983398 pan: 0 span: 1
               -15480 dirt_gate2
                 out: 38 in: 36 sustain: 0.49975594878197 fadeInTime: 0.0010000000474975 fadeTime: 0.0010000000474975 gain: 1 overgain: 0 amp: 0.40000000596046 sample: -1945774592 gateSample: 0 cut: 1 gateCut: 0 cutAllSamples: 0
         1004 dirt_delay2
           dryBus: 38 effectBus: 40 gate: 1 delaytime: 0 delayfeedback: 0 delaySend: 1 delayAmp: 0 lock: 0 cps: 0.63333332538605 resumed: 0
         1003 dirt_reverb2
           dryBus: 38 effectBus: 40 gate: 1 room: 1 size: 0.10000000149012 dry: 0 resumed: 0
         1002 dirt_leslie2
           dryBus: 38 effectBus: 40 gate: 1 leslie: 0.5 lrate: 6.6999998092651 lsize: 0.30000001192093 resumed: 0
         1001 dirt_rms2
           dryBus: 38 effectBus: 40 gate: 1 rmsReplyRate: 0 rmsPeakLag: 0 orbitIndex: 0 resumed: 0
         1000 dirt_monitor2
           dryBus: 38 effectBus: 40 outBus: 0 gate: 1 limitertype: 1 resumed: 0

Let's try the following to fix the issue:

panic

d1 $ slow 4 $ striate 32 "bev" # cut 1 # room 1

3 group
            2756 group
               -26192 dirt_sample_1_2
                 out: 36 bufnum: 376 sustain: 0.49975594878197 begin: 0.40625 end: 0.4375 speed: 1 endSpeed: 1 freq: 261.62557983398 pan: 0 span: 1
               -26200 dirt_gate2
                 out: 38 in: 36 sustain: 0.49975594878197 fadeInTime: 0.0010000000474975 fadeTime: 0.0010000000474975 gain: 1 overgain: 0 amp: 0.40000000596046 sample: -1945774592 gateSample: 0 cut: 1 gateCut: 0 cutAllSamples: 0
         2671 dirt_delay2
           dryBus: 38 effectBus: 40 gate: 1 delaytime: 0 delayfeedback: 0 delaySend: 1 delayAmp: 0 lock: 0 cps: 0.63333332538605 resumed: 0
         2670 dirt_reverb2
           dryBus: 38 effectBus: 40 gate: 1 room: 1 size: 0.10000000149012 dry: 0 resumed: 0
         2669 dirt_leslie2
           dryBus: 38 effectBus: 40 gate: 1 leslie: 0.5 lrate: 6.6999998092651 lsize: 0.30000001192093 resumed: 0
         2668 dirt_rms2
           dryBus: 38 effectBus: 40 gate: 1 rmsReplyRate: 0 rmsPeakLag: 0 orbitIndex: 0 resumed: 0
         2667 dirt_monitor2
           dryBus: 38 effectBus: 40 outBus: 0 gate: 1 limitertype: 1 resumed: 0
         1003 dirt_reverb2
           dryBus: 38 effectBus: 40 gate: -1.2000000476837 room: 1 size: 0.10000000149012 dry: 0 resumed: 0
         1001 dirt_rms2
           dryBus: 38 effectBus: 40 gate: -1.2000000476837 rmsReplyRate: 0 rmsPeakLag: 0 orbitIndex: 0 resumed: 0

It fixes the issue but the old dirt_room2 and dirt_rms2 associated with the orbits couldn't be "killed" by the panic. And they appear with a negative gate as zombie nodes. Some times I've tried this even more global effects appear as zombies.

---

• It seems the issue only happens with low timescales, the threshold is around # timescale 0.548, regardless of the sample.

[geikha]

Note the bug can generate the following inconsistencies too:

Pulsar_0WX1QfGxZ7.mp4

In this example I had done the stretching and reverb. Effectively killed the reverb. Then removed it, and could still hear this weird behaviour. I couldn't replicate this exactly with the examples given above but it seems to be related to the same issue.

(d5 is the broken one)

[telephon]

Thanks for the investigation …. It may be that the timestretching produces bad values and kills the delay which then can't be recovered the usual way.

I don't have the time right now to look into it, but I've bookmarked it.