Support |
> To combine time stretch with real-time loop manipulation > like overdub, SUSInsert, Retrigger, etc. both functions > have to be done in the same looper. After thinking about this more, I was wrong. It is complicated but it can be done. Since the hosts I use don't do time stretching I always think of stretch being applied by another plugin patched in after the looper. Here, the plugins have no control over each other and you have the problems I describe. But with the VRP, the time stretch is being done by the host which has control over the looper plugin. Audio is always processed in "blocks" which are quite small but let's exaggerate and say a block is 1 second worth of audio. At any given moment, the VRP is taking in 1 second of audio and sending out 1 second of audio. If there is no time stretching then this 1 second is simply passed through the looper plugin since they are both running at the same rate. Now let's say that you time stretch the VRP track to drop it to 1/2 speed. The VRP needs to generate 1 second of output but it only needs 1/2 second of plugin output to do that because it will be doubling the size of what is received from the plugin. So, even though we're processing a 1 second block, the host tells the plugin the block is only 1/2 second long. The plugin doesn't realize this but it is actually playing at 1/2 the speed that the host is. But we have another problem on the input side. A looper plugins is often recording at the same time that it is playing, if we tell the plugin to play 1/2 second of audio we've also got to feed it 1/2 second to record. But up in the host we've got a full second that needs to be recorded and the plugin only wants 1/2. The input must therefore be time stretched in the opposite direction, compressing 1 second down to 1/2 second to give to the plugin. So, in order to do time stretching around a plugin you have to do it twice, once to process the input sent to the plugin and again in the opposite direction to process the output of the plugin. This is basically what Mobius does when you overdub at the same time has you change speeds. What Mobius doesn't have is the ability to do a pitch shift to bring the speed adjusted audio back to the original pitch like the VRP does. > It must be a hell of a scary amount of programming to scare off the > likes of Jeff Larsen Changing the speed isn't hard, it is the pitch shifting that's hard. This requires knowledge of DSP (digital signal processing) algorithms which is a specialized skill that not many programmers have. There are lots of algorithms published on the web that sound great, but they require too much computer processing and can't be used in real time. The ones that are fast tend to add weird artifacts to the sound. The trick is to find the balance between good sound and fast processing. At the end of the day it isn't a lot of code, it's a lot of mathematics, and I basically suck at math :-) Jeff