posted 22 January 2015 13:13            

Recently I've been thinking about TimeStretching a live input. I have come this far: Write a frame of spectral data using the memorywriter (cyclic). Use a waveshaper and a FullRamp to read out the frames continously at double speed using framelength (e.g. 256) * 0.5 for the fullramp frequency. Write that to the ram with another memorywriter. Read out with a sample module with default * 0.5 for the frequency field. Now I can do a realtime halfspeed timestretch because I'm effectively playing each frame twice. I could do the same for quarterspeed using 0.25 instead of 0.5.

However I can't do any stretches in between because then the frames get out of sync and/or are just partially written. I also messed a little bit with the interpolate module to generate the frames "between" frames if you know what I mean. I think I can also figure that out for half or quarterspeed but what I really want to do is a smooth timestretch up to freezing and back (to the future? ) again.

Any clues? I've been thinking about reading out the second memory writer with a waveshaper + fullramp (or another control function?) combo again but my mind is twisted now

posted 24 January 2015 08:13            

This is one of those things that is so easy in DSP assembly and I have a module called SOSstretch for the cappy. I think it may be one of the modules SSC will remake for paca but not sure.

Anyway for the paca as it stands, the main thing to think about here is that there is a limit to how much time stretching you can do (unless you had infinite ram). Lets say we chose a max of 2048 frames and the frame length was 256. If we start with a cyclic memory writer of (256*2048) samp, then we need a reading wave shaper to match. We need to feed the index of the wave shaper with a tiny ramp and a big ramp added together, where the tiny ramp is 1/2048 in size and running at a fix 256 samp period to match the frame rate. It has to be offset to start at zero (not a minus number) so a scale and offset module can do both the size reduction and the offset.

The big ramp will move from -1 to +1 but must be staircase in shape such that it will only ever give values that equate to the first partial in the frame. By removing the 8 lowest bits from the ramp we can guarantee that the nearest/lower partial numbered one will be outputted. You can do this with a bit crusher which is simply putting the ramp through a mixer with gain set to 1/256 and then through a gain module which is set to 256, to get the ramp back to full size -1 to+1.

The rate of the big ramp will be at normal speed if the period is set to (256*1048) samples , but can be slowed down to make the time stretch (or sped up if it has been slow for a while). It is probably a good idea to make an indicator on the VCS using a second big ramp fixed at (256*1048) samples period as a reference, so that it can be compared with the variable big ramp time controller and feed to a StoGC to display where you are as far as offset to real time. Don't forget to compensate for wrap around. This can be done in capytalk inside the StoGC. To do this, half the size of both ramps before subtracting one from the other and if the value goes below 0.5 add one to it, other wise just output the value.

Interpolating between frames is a bit harder but the general idea is to have two waveshapers ones index offset by one frame (+1/1048). Then by subtracting the bit crushed big ramp from the un bit crushed big ramp and scaling it up to a range of 0 to 1. You can then use it to control a sample rate interpolator (as used in the sample rate smoother we did before) to interpolate between the two waveshapers outputs. The only problem is the wrap around that happens when the big ramp reaches +1. We had sample rate wrap around mixers for the capybara in pete's DSP code that could have dealt with this, but not in the paca. I've posted some sample rate wrap around sounds for pacarana but I can't guarantee their integrity.

posted 26 January 2015 01:37            

DriftingSpectrum.kym

quote:

---

This is one of those things that is so easy in DSP assembly and I have a module called SOSstretch for the cappy. I think it may be one of the modules SSC will remake for paca but not sure.

---

quote:

---

Anyway for the paca as it stands, the main thing to think about here is that there is a limit to how much time stretching you can do (unless you had infinite ram). Lets say we chose a max of 2048 frames and the frame length was 256. If we start with a cyclic memory writer of (256*2048) samp, then we need a reading wave shaper to match. We need to feed the index of the wave shaper with a tiny ramp and a big ramp added together, where the tiny ramp is 1/2048 in size and running at a fix 256 samp period to match the frame rate. It has to be offset to start at zero (not a minus number) so a scale and offset module can do both the size reduction and the offset.

---

quote:

---

The big ramp will move from -1 to +1 but must be staircase in shape such that it will only ever give values that equate to the first partial in the frame. By removing the 8 lowest bits from the ramp we can guarantee that the nearest/lower partial numbered one will be outputted. You can do this with a bit crusher which is simply putting the ramp through a mixer with gain set to 1/256 and then through a gain module which is set to 256, to get the ramp back to full size -1 to+1.

---

quote:

---

The rate of the big ramp will be at normal speed if the period is set to (256*1048) samples , but can be slowed down to make the time stretch (or sped up if it has been slow for a while). It is probably a good idea to make an indicator on the VCS using a second big ramp fixed at (256*1048) samples period as a reference, so that it can be compared with the variable big ramp time controller and feed to a StoGC to display where you are as far as offset to real time. Don't forget to compensate for wrap around. This can be done in capytalk inside the StoGC. To do this, half the size of both ramps before subtracting one from the other and if the value goes below 0.5 add one to it, other wise just output the value.

---

quote:

---

Interpolating between frames is a bit harder but the general idea is to have two waveshapers ones index offset by one frame (+1/1048). Then by subtracting the bit crushed big ramp from the un bit crushed big ramp and scaling it up to a range of 0 to 1. You can then use it to control a sample rate interpolator (as used in the sample rate smoother we did before) to interpolate between the two waveshapers outputs. The only problem is the wrap around that happens when the big ramp reaches +1. We had sample rate wrap around mixers for the capybara in pete's DSP code that could have dealt with this, but not in the paca. I've posted some sample rate wrap around sounds for pacarana but I can't guarantee their integrity.

---

posted 26 January 2015 13:57            

I don't have a pacarana at the moment so can't check the drifting but try one extra or one less sample in the number of samples in the writer and see if it pulls it in?

sample and hold at 256 won't work because the big ramp will vary in gradient and you want the staircase to rest on a value that represents the frame edge in ram not the point in time on the big ramp when the frame edge happens as that could land on any partial in ram.

I've just realised that removing the 8 lowest bits won't guarantee a frame edge. To do that we need to remove a lot more of the lower bits to ensure that there are only 2048 possible results/values from the big ramp, and every one of those values will be the frame edge in RAM. In other words we need to leave only the 11 MSbits, and if the paca is using 32 bit we need to remove 21 of the lower bits. This will need some experimentation. A 256 sample and hold could be used here in addition so as to stop the jump between frames mid frame.

Your correct it is a typo and your guess is right.

Actually I've got the interpolating a bit wrong. This would need an additional sample and hold at 256 samp to lock the stair case at a fixed frame for the duration of the frame.

posted 26 January 2015 16:00            

I'll check that tomorrow, hope it removes the drifting!

You're right, I haven't thought about changing the frequency of the big ramp. It only works as long as I'm using the big ramp at (256*2048) samp hz.

One way would be to record the big ramp with a sampleAndHold (256 samp) with a memorywriter (not cyclic) and use that as a wavetable for another oscillator with interpolation unchecked.
Another way could be using the XenOscillator. I'll see what fits..

Definitely some sampleAndHolds at 256 samp need to be used to avoid mid-frame jumps and/or interpolation. BTW I found the SR interpolate Haven't checked out the Wrappers though...

posted 27 January 2015 02:40            

About the interpolation: I think it is the other way around, I have to subtract the un-bitcrushed from the bit-crushed. Also there's no need for wrapping

posted 27 January 2015 13:01            

How does it drift. Does it come back in sync after a (256*2048) cycle?

posted 27 January 2015 14:53            

Oh, now I see why I need the wrapping! I haven't thought that through because I'm still struggling with the drift. I think I can do that with your SRWrapModules. I've looked at them today and except for the equality bug everything is fine! Have you tried using the Waveshaper for SR wrapping?