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
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@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
Dear Gloria,
You could have a look at Piro that is currently under development:
On 11 Apr 2021, at 17:25, Marco Matteo Markidis <mm.markidis@gmail.com mailto:mm.markidis@gmail.com> wrote:
Dear all,
I would like to announce the release of *piro*[1]. Piro is a Pd-port of an impulse-response measurement object and a zero latency convolver from the HISSTools Impulse Response Toolbox (HIRT). Moreover in the package it is included a general-purpose object that contains several utilities for managing IRs; this is still in progress. Source code and binary for major architectures are provided. For any questions about the Pd version of these objects please do not hesitate to contact me. Moreover in the readme there is a link for the original project, where you can find an article that describes the original package and its utilities.
Finally I would like to thank Lucas Cordiviola and Giuseppe Silvi for their patience with this project.
Best, Marco
[1]: https://github.com/d-i-s/piro https://github.com/d-i-s/piro
Best!
Edwin
On 3 May 2021, at 18:27, Gloria Dal Santo gloria.dalsanto@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
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
-
Edwin van der Heide -
Gloria Dal Santo -
katja