Hi everyone. Although similar topics have been discussed before, I couldn't find a good solution to my problem. I'd like to build an effects processor, in which a user will record some sound, then listen to it with different effects. For example, after the recording, the user will press a button and hear it with the reverb, press a button and hear it with phasor, etc. To do this, I need to build a patch that will apply the fx offline, i.e., non real-time. Right now, I can only apply the effects by playing the recorded sound file through one of the fx chains, and record the result, and playback the "wet" sound file. Obviously, the longer the sound file, the longer the waiting time. Is there a way to tell PD to calculate how the fx is going to change the sound and write it to a sound file that will be played later? I feel like I couldn't describe myself clearly, but I think you can understand my problem.

The second issue is, how to build the effects resource-effective. Is there a way to stop an fx chain (let's say, reverb) from working until it is required (without turning the DSP off, of course)? This would be quite nice as I don't want an effect to work in the background and use up the resources until a user needs to use it.

Thanks in advance for any kind of help. It would be great if I can get through these obstacles and start the fun part of patching!

if your effects are in subpatches or made as abstractions, then just use [switch~] to turn the DSP on/off locally inside.

If you do that, it is possible to load dozens, probably even hundreds of effects at once, and only activate the one(s) that you need.

Thanks! That's what I was looking for to switch the dsp off in subpatches. That'll help me a lot.

Now I must find a way to apply fx offline. I wonder how it's done in the daws. There should be a known way (or an algorithm) for that, since probably none of the commercial plug-ins come with an option for offline bounce but most daws (ok, except Pro-Tools) do it anyway. I'm aware that PD is mostly a proud real-time environment but someone must have gotten some use for offline processing as well.

by using upsampling (again, see the switch~ helpfile) you should be able to do all your processing at much higher sample rates, ie 32 times normal or something. So all your sounds would just be done as a very high pitched chipmunk blur.

However, for actually saving those samples, i'm not so sure how writesf~ will deal with the downsampling to make them normal again. It might be as simple as just setting the sample rate to 44.1khz or whatever rate you want to go for.

If you can use tables to store the sounds, you could set up something using [until], a counter and [tabread]/[tabwrite] to process the samples as fast as possible. Keep in mind that it'll block until the processing is done, which means you'll probably have audio dropouts if you're listening at the same time. Not sure if that's a problem for you or not.

Here's a quick patch i threw together to process 10 seconds of 1hz phasor~ waveform at 32 times upsampling. So, the soundfile is created in about 300ms (plus overhead for actual file writing processes)

a normal pd block has 64 samples and no upsampling. By creating a switch~ object like [switch~ 64 1 32], you tell pd to process 32 times more samples for each unit of time.

However, you now also have to scale everything else in your patch to match this upsampled rate. My test patch here uses a simple [phasor~] waveform, and my aim is to create 10 cycles in 10 seconds, so at normal samplerate i would just use a 1hz phasor~. However, because i am upsampling by a factor of 32, i need to also multiply the phasor~ rate by this same factor, ie [phasor~ 32]

basically, anything in your patch that is dependent on time or frequency, you will need to scale accordingly. So, for example, if you want to create a simple delay effect, with a 500ms delay time, then in your upsampled patch, you will need to make this 32 times faster, ie 500ms divided by 32.

Likewise, if you want to make a filter with a cutoff at 1000hz, you will need to scale this so that the cutoff frequency is 32 times higher at 32000hz.

anything in your effects patches that are dependent on time or frequency, you will have to think carefully about and scale accordingly. This also includes any control objects such as [line], [metro], [delay] and stuff like that, which depend on time.

obviously, if you're using samples, then instead of my [phasor~] example, you'd want to drive a table using [tabread4~]. This should also of course be driven 32 times too fast.

a couple more notes (if you haven't given up already):

i tested with 32 times upsampling, and it seems to work ok for this very simple example. However, when i tried with 128 times upsampling, it started to get a bit buggy. Any small glitches in timing at normal block size, are going to be magnified by whatever factor of oversampling you choose. You might need to use trial and error a bit to find the best rate to run at.

once you get a few fx processes running, it may be more efficient to increase the blocksize as well. so, instead of [switch~ 64 1 32], something like [switch~ 4096 1 32] may be more beneficial. Again, you might just need to use trial and error to find the best block size.

http://www.pdpatchrepo.info/hurleur/upsampled-processing.pd

@mod said:

by using upsampling (again, see the switch~ helpfile) you should be able to do all your processing at much higher sample rates, ie 32 times normal or something. So all your sounds would just be done as a very high pitched chipmunk blur.

However, for actually saving those samples, i'm not so sure how writesf~ will deal with the downsampling to make them normal again. It might be as simple as just setting the sample rate to 44.1khz or whatever rate you want to go for.

I think recording the upsampled audio and downsampling in a DAW would be better, unless someone comes up with a really solid set of FIR filters explicitly for that purpose.

There are sometimes issues with upsampling, too. First you have to make sure the sound of your patch isn't (adversely) affected by increasing the sample rate. If you're doing things like setting filter coefficients manually, you could have some unpleasant surprises. Second, biquad filters can become very noisy at high sample rates. IMO the biquads need to be fully 64 bit (coefficients and internally) before this is really a good idea.

The patch you uploaded doesn't seem to work, when I play the sound file no noise comes out...

I have been looking into doing this and have had mixed results. I had a granular patch working nicely up to 8 times as fast without any glitching or artefacts. I had it working well with a filter as well but I am having real trouble getting this to work with a delay effect. I have modified one of the example reverb patches and it implements the reverb in the output file though the scale of the effect is totally incorrect. I am wondering if I am missing something in the calculations. I have attached , the admittedly crude mod of the patch. The reverb is a sub patch, I am simply dividing the delay times by 8 when processing.

http://www.pdpatchrepo.info/hurleur/bounce.zip