Because it's too expensive.
Using the CPU meter in Pd, I'm getting at 48k with our waveguide patch
which has 5 delreads in it
delread4~
1x 12%
2x 21%
4x 33%
delreadsinc~
1x 15%
2x 26%
4x 39%
In effect it's delreadsinc~ at 15% (because it doesn't need upsampling)
versus a 4-fold upsampled
On Thu, Apr 29, 2021 at 12:08 PM Clemens Wegener wrote:
> Also: Is it really mandatory to choose a filter cutoff below pi, when the
> input and output Sample rates match? For a simple static delay that should be
> the case.
There is an exact requirement when what you're making is an
@Miller, I just saw your message - we will try that asap!
Hello Chuck,
Good point! Thanks for these thoughts, there is no good reason to duplicate the
table with each object, apart from initially being too lazy to code it
correctly.
I will have a look at the code again and see which
I think this is a bit too application-specific to put in Pd vanilla... but
anyway, I don't understand why you can't just run the entire waveguide
at 4x sample rate - am I missing something?
cheers
M
On Thu, Apr 29, 2021 at 02:06:11PM +0200, Max wrote:
> Hi Miller,
>
> I think the oversampling
It's sort of disappointing that it has to be so expensive, but you do
what you have to to get the quality and consistency of the sound. The
question of whether there is an optimal interpolating kernel (which
I'd like to work on) isn't really going to help you in the near term.
It's enough just to
Hi Miller,
I think the oversampling workaround is great for cases like slow
playback of a sound file, but I'm not sure how this would work in a
waveguide, ans particularly our situation where we have different timbre
depending on if the number of samples in the delay line is odd or even.
