Re: [PD] delay compensation in pitch-shifting

[i...@hansroels.be]

see the attached patch.
I now think it is impossible to compensate for the delay of a variable 
delay pitch shifter. Just because it's variable :) Anyway, this is 
Miller's clear explanation: 
http://msp.ucsd.edu/techniques/latest/book-html/node115.html


best, Hans

On 11/24/20 2:59 PM, Maximiliano Estudies wrote:


Hi Hans,

how are you measuring the delays?

Cheers,
Maxi

El vie, 20 nov 2020 a las 15:25, i...@hansroels.be 
 (>) escribió:


Hello,

Hopefully people with more knowledge of audio processing can
answer the following questions. Background: I make patches in
which the microphone input is modified by different kinds of
pitch-shifting, I would like to compensate the delays caused by
these pitch-shifts and thus avoid artefacts.

1) How much delay does a pitch-shifter based on a variable delay
(the classic rotating-tape-head style) produce? as in
G09.pitchshift.pd in the audio.examples folder. I did a quick test
with a one-sample-audio-trigger going immediately to the first
channel of a recording patch in Pd and simultaneously going to a
variable delay pitchshift (pp.pitchshift~ from AudioLab), routed
into the second channel of the recorder. The delays are quite
large and vary between 30 and 80 milliseconds, there seems to be
no relation with the amount of pitch-shift. In the pitch-shifting
patch I also notice that the delay varies between zero and the
window size. Is there a way/patch to calculate and compensate for
this delay? (for example, if you want to combine the original with
the pitch-shifted signal in a patch). Or is this impossible
because the delay is variable...

2) I'd like to know the delay in ms with FFT processing if you
have a 1024 sample window with overlap factor of 4, for example,
in a pitch-shifting vocoder? I found this info on a MAx/MSP
mailing list, is it correct?: "The I/ O delay is equal to the
window size minus the hop size (e.g., for a 1024-sample FFT window
with an overlap factor of 4, the hop size is equal to 256, and the
overall delay from input to output is 768 samples)"; at 44100
sampling rate this is around 17ms delay (for a window of 1024
samples, overlap 4).

3) Conclusion: any pitch-shifting technique introduces tens of
milliseconds delay? (Pitch-shifting based on granular synthesis is
not a solution, I think it also requires a buffer of at least 50ms.)

Hans

-- 
___

Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list



--
Maximiliano Estudies
/VDT Referat Beschallung/
+49 176 36784771
omslo.com 
maxiestudies.com 



--
#N canvas 574 82 482 292 12;
#N canvas 1 58 450 258 one-sample-burst 0;
#X obj 174 199 outlet~;
#N canvas 595 92 466 478 crackle 0;
#X obj 116 152 / 44.1;
#X obj 108 399 vline~;
#X obj 108 426 outlet~;
#X obj 174 94 samplerate~;
#X obj 137 68 t f b;
#X obj 51 244 f;
#X text 131 9 aantal samples;
#X obj 95 280 t b f b;
#X msg 143 326 1;
#X msg 88 340 0;
#X obj 90 312 del;
#X obj 158 123 * 0.001;
#X obj 246 14 loadbang;
#X obj 246 39 5;
#X obj 137 30 r 1-craslen;
#X obj 42 126 inlet bang;
#X connect 0 0 5 1;
#X connect 1 0 2 0;
#X connect 3 0 11 0;
#X connect 4 0 0 0;
#X connect 4 1 3 0;
#X connect 5 0 7 0;
#X connect 7 0 10 0;
#X connect 7 1 10 1;
#X connect 7 2 8 0;
#X connect 8 0 1 0;
#X connect 9 0 1 0;
#X connect 10 0 9 0;
#X connect 11 0 0 1;
#X connect 12 0 13 0;
#X connect 13 0 4 0;
#X connect 14 0 4 0;
#X connect 15 0 5 0;
#X restore 176 113 pd crackle;
#X obj 175 160 *~ 0.5;
#X obj 170 47 inlet;
#X connect 1 0 2 0;
#X connect 2 0 0 0;
#X connect 3 0 1 0;
#X restore 159 83 pd one-sample-burst;
#N canvas 1 58 450 300 record2channels 0;
#X obj 99 42 inlet~;
#X obj 187 45 inlet~;
#X restore 38 198 pd record2channels;
#N canvas 1 58 450 300 pitchshifter 0;
#X obj 187 45 inlet~;
#X obj 159 262 outlet~;
#X restore 160 141 pd pitchshifter;
#X obj 159 43 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 124 169 dac~;
#X text 37 230 ...and compare both audio channels in an audio editor.
;
#X text 277 139 <- put your variable delay pitchshifter in here, f
26;
#X connect 0 0 2 0;
#X connect 0 0 1 0;
#X connect 0 0 4 0;
#X connect 2 0 1 1;
#X connect 2 0 4 1;
#X connect 3 0 0 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] delay compensation in pitch-shifting

[Maximiliano Estudies]

Hi Hans,

how are you measuring the delays?

Cheers,
Maxi

El vie, 20 nov 2020 a las 15:25, i...@hansroels.be ()
escribió:

> Hello,
>
> Hopefully people with more knowledge of audio processing can answer the
> following questions. Background: I make patches in which the microphone
> input is modified by different kinds of pitch-shifting, I would like to
> compensate the delays caused by these pitch-shifts and thus avoid
> artefacts.
>
> 1) How much delay does a pitch-shifter based on a variable delay (the
> classic rotating-tape-head style) produce? as in G09.pitchshift.pd in the
> audio.examples folder. I did a quick test with a one-sample-audio-trigger
> going immediately to the first channel of a recording patch in Pd and
> simultaneously going to a variable delay pitchshift (pp.pitchshift~ from
> AudioLab), routed into the second channel of the recorder. The delays are
> quite large and vary between 30 and 80 milliseconds, there seems to be no
> relation with the amount of pitch-shift. In the pitch-shifting patch I also
> notice that the delay varies between zero and the window size. Is there a
> way/patch to calculate and compensate for this delay? (for example, if you
> want to combine the original with the pitch-shifted signal in a patch). Or
> is this impossible because the delay is variable...
>
> 2) I'd like to know the delay in ms with FFT processing if you have a 1024
> sample window with overlap factor of 4, for example, in a pitch-shifting
> vocoder? I found this info on a MAx/MSP mailing list, is it correct?: "The
> I/ O delay is equal to the window size minus the hop size (e.g., for a
> 1024-sample FFT window with an overlap factor of 4, the hop size is equal
> to 256, and the overall delay from input to output is 768 samples)"; at
> 44100 sampling rate this is around 17ms delay (for a window of 1024
> samples, overlap 4).
>
> 3) Conclusion: any pitch-shifting technique introduces tens of
> milliseconds delay? (Pitch-shifting based on granular synthesis is not a
> solution, I think it also requires a buffer of at least 50ms.)
>
> Hans
> --
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>


-- 
Maximiliano Estudies
*VDT Referat Beschallung*
+49 176 36784771
omslo.com
maxiestudies.com
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] delay compensation in pitch-shifting

[João Pais]

this doesn't answer your question but: does my port of Henke's Granulator
[jmmmp/Granulator] improve your problem in any way?

On Fri, 20 Nov 2020 at 15:25, i...@hansroels.be  wrote:

> Hello,
>
> Hopefully people with more knowledge of audio processing can answer the
> following questions. Background: I make patches in which the microphone
> input is modified by different kinds of pitch-shifting, I would like to
> compensate the delays caused by these pitch-shifts and thus avoid
> artefacts.
>
> 1) How much delay does a pitch-shifter based on a variable delay (the
> classic rotating-tape-head style) produce? as in G09.pitchshift.pd in the
> audio.examples folder. I did a quick test with a one-sample-audio-trigger
> going immediately to the first channel of a recording patch in Pd and
> simultaneously going to a variable delay pitchshift (pp.pitchshift~ from
> AudioLab), routed into the second channel of the recorder. The delays are
> quite large and vary between 30 and 80 milliseconds, there seems to be no
> relation with the amount of pitch-shift. In the pitch-shifting patch I also
> notice that the delay varies between zero and the window size. Is there a
> way/patch to calculate and compensate for this delay? (for example, if you
> want to combine the original with the pitch-shifted signal in a patch). Or
> is this impossible because the delay is variable...
>
> 2) I'd like to know the delay in ms with FFT processing if you have a 1024
> sample window with overlap factor of 4, for example, in a pitch-shifting
> vocoder? I found this info on a MAx/MSP mailing list, is it correct?: "The
> I/ O delay is equal to the window size minus the hop size (e.g., for a
> 1024-sample FFT window with an overlap factor of 4, the hop size is equal
> to 256, and the overall delay from input to output is 768 samples)"; at
> 44100 sampling rate this is around 17ms delay (for a window of 1024
> samples, overlap 4).
>
> 3) Conclusion: any pitch-shifting technique introduces tens of
> milliseconds delay? (Pitch-shifting based on granular synthesis is not a
> solution, I think it also requires a buffer of at least 50ms.)
>
> Hans
> --
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] delay compensation in pitch-shifting (i...@hansroels.be)

[IOhannes m zmölnig]

On 11/24/20 10:41 AM, Christof Ressi wrote:
@Hans Looking at the makefile, I think you're supposed to run either 
"make pd_darwin" (for macOS) or "make pd_nt" (for Windows with MSVC). 
There seems to be no Linux support.


@Julian: Consider using "pd-lib-builder" instead of handwritten 
makefiles, as this is the build system used by most recent Pd externals. 
The makefile then becomes trivial and it automatically works on all 
major platforms (with GCC or clang):


|# Makefile for shifter~ lib.name = shifter~ class.sources = shifter~.c 
datafiles = shifter~-help.pd include Makefile.pdlibbuilder |


please use a settable path for the pd-lib-builder makefile, even if it 
is in the same directory:


```
# Makefile for shifter~
lib.name = shifter~
class.sources = shifter~.c
datafiles = shifter~-help.pd
PDLIBBUILDER_DIR=.
include $(PDLIBBUILDER_DIR)/Makefile.pdlibbuilder
```

it's probably all the same to you, but makes packaging much easier.

fmgrdsa
IOhannes

PS: I should update the pd-lib-builder README ;-)



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] delay compensation in pitch-shifting (i...@hansroels.be)

[Christof Ressi]

@Hans Looking at the makefile, I think you're supposed to run either 
"make pd_darwin" (for macOS) or "make pd_nt" (for Windows with MSVC). 
There seems to be no Linux support.


@Julian: Consider using "pd-lib-builder" instead of handwritten 
makefiles, as this is the build system used by most recent Pd externals. 
The makefile then becomes trivial and it automatically works on all 
major platforms (with GCC or clang):


|# Makefile for shifter~ lib.name = shifter~ class.sources = shifter~.c 
datafiles = shifter~-help.pd include Makefile.pdlibbuilder |


This assumes that "Makefile.pdlibbuilder" is located next to the 
makefile. You can compile by simple typing "make" or install with "make 
install".


More information here: https://github.com/pure-data/pd-lib-builder

Christof

||

On 24.11.2020 10:09, i...@hansroels.be wrote:

Hi Julian,
Thanks for informing about your port of [shifter~]! I tried to compile 
[shifter~] on ubuntu studio but after the 'make shifter~' command I 
get a list of messages like:

undefined reference to 'main'
undefined reference to 'pd_new'
undefined reference to 'pd_new' 'floatinlet_new'
...

best, Hans
On 11/24/20 5:30 AM, Peter P. wrote:

Nice Juliàn, is that a variable-delay ("rotating head") pitch shifter as
well? In that case, how would it compare to G09.pitchshift.pd ?
cheersz, P

* Julián Villegas  [2020-11-24 03:45]:

Hi Hans,

I’m sorry I’m late to the party and that I can’t answer your questions, but I 
wanted to call your attention to [shifter~], this is a PSOLA pitch shifter 
object that I ported to Pd from its eponymous version in Max-MSP, developed by 
Tristan Jehan. The source code and MacOS compiled library are here:

https://bitbucket.org/julovi/shifter/src/master/

Cheers,

Julian.






___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list



--

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] delay compensation in pitch-shifting (i...@hansroels.be)

[i...@hansroels.be]

Hi Julian,
Thanks for informing about your port of [shifter~]! I tried to compile 
[shifter~] on ubuntu studio but after the 'make shifter~' command I get 
a list of messages like:

undefined reference to 'main'
undefined reference to 'pd_new'
undefined reference to 'pd_new' 'floatinlet_new'
...

best, Hans
On 11/24/20 5:30 AM, Peter P. wrote:

Nice Juliàn, is that a variable-delay ("rotating head") pitch shifter as
well? In that case, how would it compare to G09.pitchshift.pd ?
cheersz, P

* Julián Villegas  [2020-11-24 03:45]:

Hi Hans,

I’m sorry I’m late to the party and that I can’t answer your questions, but I 
wanted to call your attention to [shifter~], this is a PSOLA pitch shifter 
object that I ported to Pd from its eponymous version in Max-MSP, developed by 
Tristan Jehan. The source code and MacOS compiled library are here:

https://bitbucket.org/julovi/shifter/src/master/

Cheers,

Julian.






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



--
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] delay compensation in pitch-shifting (i...@hansroels.be)

[Peter P.]

Nice Juliàn, is that a variable-delay ("rotating head") pitch shifter as
well? In that case, how would it compare to G09.pitchshift.pd ?
cheersz, P

* Julián Villegas  [2020-11-24 03:45]:
> Hi Hans,
> 
> I’m sorry I’m late to the party and that I can’t answer your questions, but I 
> wanted to call your attention to [shifter~], this is a PSOLA pitch shifter 
> object that I ported to Pd from its eponymous version in Max-MSP, developed 
> by Tristan Jehan. The source code and MacOS compiled library are here:
> 
> https://bitbucket.org/julovi/shifter/src/master/
> 
> Cheers,
> 
> Julian.
> 
> 
> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] delay compensation in pitch-shifting (i...@hansroels.be)

[Julián Villegas]

Hi Hans,

I’m sorry I’m late to the party and that I can’t answer your questions, but I 
wanted to call your attention to [shifter~], this is a PSOLA pitch shifter 
object that I ported to Pd from its eponymous version in Max-MSP, developed by 
Tristan Jehan. The source code and MacOS compiled library are here:

https://bitbucket.org/julovi/shifter/src/master/

Cheers,

Julian.






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] delay compensation in pitch-shifting

[i...@hansroels.be]

Hello,

Hopefully people with more knowledge of audio processing can answer the 
following questions. Background: I make patches in which the microphone 
input is modified by different kinds of pitch-shifting, I would like to 
compensate the delays caused by these pitch-shifts and thus avoid 
artefacts.


1) How much delay does a pitch-shifter based on a variable delay (the 
classic rotating-tape-head style) produce? as in G09.pitchshift.pd in 
the audio.examples folder. I did a quick test with a 
one-sample-audio-trigger going immediately to the first channel of a 
recording patch in Pd and simultaneously going to a variable delay 
pitchshift (pp.pitchshift~ from AudioLab), routed into the second 
channel of the recorder. The delays are quite large and vary between 30 
and 80 milliseconds, there seems to be no relation with the amount of 
pitch-shift. In the pitch-shifting patch I also notice that the delay 
varies between zero and the window size. Is there a way/patch to 
calculate and compensate for this delay? (for example, if you want to 
combine the original with the pitch-shifted signal in a patch). Or is 
this impossible because the delay is variable...


2) I'd like to know the delay in ms with FFT processing if you have a 
1024 sample window with overlap factor of 4, for example, in a 
pitch-shifting vocoder? I found this info on a MAx/MSP mailing list, is 
it correct?: "The I/ O delay is equal to the window size minus the hop 
size (e.g., for a 1024-sample FFT window with an overlap factor of 4, 
the hop size is equal to 256, and the overall delay from input to output 
is 768 samples)"; at 44100 sampling rate this is around 17ms delay (for 
a window of 1024 samples, overlap 4).


3) Conclusion: any pitch-shifting technique introduces tens of 
milliseconds delay? (Pitch-shifting based on granular synthesis is not a 
solution, I think it also requires a buffer of at least 50ms.)


Hans

--
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list