From gloria.dalsanto at outlook.it Mon May 3 18:27:19 2021 From: gloria.dalsanto at outlook.it (Gloria Dal Santo) Date: Mon, 3 May 2021 16:27:19 +0000 Subject: [PD-dev] [partconv~] limitations Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From katjavetter at gmail.com Mon May 3 22:10:48 2021 From: katjavetter at gmail.com (katja) Date: Mon, 3 May 2021 22:10:48 +0200 Subject: [PD-dev] [partconv~] limitations In-Reply-To: References: Message-ID: 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 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 > > From pd at evdh.net Mon May 3 22:27:00 2021 From: pd at evdh.net (Edwin van der Heide) Date: Mon, 3 May 2021 22:27:00 +0200 Subject: [PD-dev] [partconv~] limitations In-Reply-To: References: Message-ID: <68454F2B-0BA6-422E-A699-F112DD93B866@evdh.net> Dear Gloria, You could have a look at Piro that is currently under development: > On 11 Apr 2021, at 17:25, Marco Matteo Markidis > 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 Best! Edwin > On 3 May 2021, at 18:27, Gloria Dal Santo 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 at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: