[PD-dev] [partconv~] limitations

[katja]

Years ago I ran into the same dropout issue when switching partconv~
IR that could not be solved by multiplexing with smooth overlap. Back
then I had a look into the C code and (off the top of my head) my
conclusion was that it might be a CPU spike related to the underlying
FFTW library making a new "plan" for optimal FFT calculation every
time when partconv~ switches filter definition (even when filter
length remains unaltered). If that is true, not easy to fix.

Katja



On 5/3/21, Gloria Dal Santo <gloria.dalsanto at outlook.it> wrote:
> Hi everyone,
>
> After playing with partconv~ in other to implement a patch for sound
> externalization I am asking myself whether what I am trying to do is maybe
> too much for pure data or not.
>
> To sum up, I need to convolve a sound file with a BRIR that is updated
> whenever the listener moves his head, so that to simulate a fixed sound
> source.
> I already have a dataset of 36 impulse responses, each of size 8192
> samples.
>
> [partconv~] allows to change the impulse response by sending a [set ir_name(
> message. (For [convolve~] the message would be [set ir_name( ).
> Unfortunately, as soon as I send the [set _ ( message the audio stopes for a
> little while. Why is it so? I tried to dig into the code and I guess is
> simply because the buffers are freed when the set method is called.
>
> I tried to define larger buffers so that I can store multiple BRIRs and have
> access to them without freeing the buffers (even though extra care must be
> taken in the perform method) but I think I don’t have enough coding skills
> to do that.
>
> I then tried to use 5 [partconv~]s for each channel (thus 10 [partconv~]s)
> running at the same time with different BRIRs and multiplexing between
> them.
> The idea is that of switching between the outputs of the [partconv~] that
> are not updating their BRIRs, while one of the [partconv~] is actually
> updating it according to the direction of the head.
> To achieve this I’m using the [mux~] object.
> The idea seems working, but it actually doesn’t. When I switch  between
> [mux~]  inputs sometimes I get clicks. On the spectrogram these look like
> vertical lines of constant values (like noise).
> What could be the reason? Do you think that having 10  [partconv~] running
> at the same time is too much?
>
> Thank you in advance for your time,
> With my best regard,
>
> Gloria
>
>