pvs and spectral warping (as in GRM tools)

[peiman]

Hello all,

What is the best way to rearrange amplitude data in an FFT frame using
pvs signal?

I basically want to swap the amplitude data of one bin with another
before synthesizing the FFT frame. So for instance to say that I want
the amplitude of bin one to be swapped with the amplitude of bin 10
and so on, but for every bin. I have tried pvsftw and vcopy but the
result is very wobbly and not what I expected at all.

The aim is to imitate the GRM tools spectral Warp. Is this possible?

Many thanks in advance

Best
Peiman


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Victor Lazzarini]

One thing you might try is do substantial pitch shifting or
frequency shifting,
which will move the amplitudes, then recombining the
freqs of the original signal with the shifted amplitudes
using pvsvoc.

But I guess it's also possible to do it using tables.

Victor

----- Original Message -----
From: "peiman khosravi" <peimankhosravi@...>
To: <csound@...>
Sent: Monday, March 02, 2009 2:15 PM
Subject: [Csnd] pvs and spectral warping (as in GRM tools)

> Hello all,
>
> What is the best way to rearrange amplitude data in an FFT frame using
> pvs signal?
>
> I basically want to swap the amplitude data of one bin with another
> before synthesizing the FFT frame. So for instance to say that I want
> the amplitude of bin one to be swapped with the amplitude of bin 10
> and so on, but for every bin. I have tried pvsftw and vcopy but the
> result is very wobbly and not what I expected at all.
>
> The aim is to imitate the GRM tools spectral Warp. Is this possible?
>
> Many thanks in advance
>
> Best
> Peiman
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[peiman]

Thanks for reply,

That's a very interesting idea will try it tomorrow. I finaly managed
to implement it as a udo using tables. I'll post the code here soon.

Thanks
Peiman



2009/3/2 victor <Victor.Lazzarini@...>:

> One thing you might try is do substantial pitch shifting or
> frequency shifting,
> which will move the amplitudes, then recombining the
> freqs of the original signal with the shifted amplitudes
> using pvsvoc.
>
> But I guess it's also possible to do it using tables.
>
> Victor
>
> ----- Original Message ----- From: "peiman khosravi"
> <peimankhosravi@...>
> To: <csound@...>
> Sent: Monday, March 02, 2009 2:15 PM
> Subject: [Csnd] pvs and spectral warping (as in GRM tools)
>
>
>> Hello all,
>>
>> What is the best way to rearrange amplitude data in an FFT frame using
>> pvs signal?
>>
>> I basically want to swap the amplitude data of one bin with another
>> before synthesizing the FFT frame. So for instance to say that I want
>> the amplitude of bin one to be swapped with the amplitude of bin 10
>> and so on, but for every bin. I have tried pvsftw and vcopy but the
>> result is very wobbly and not what I expected at all.
>>
>> The aim is to imitate the GRM tools spectral Warp. Is this possible?
>>
>> Many thanks in advance
>>
>> Best
>> Peiman
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"
>

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[David Mooney/Maxine Heller]

Similarly, I've attempted to use vpvoc and tableseg for spectral
warping operations, but this does not seem to work (using the example
in the Csound Book as a test using a file created with pvanal. The
file works fine with pvoc). Before spending more time on this, am I
recalling correctly that there is some problem with vpvoc in 5.x? Is
there something else Peiman and I should be using?

Thanks--

--David

At 09:15 AM 3/2/2009, you wrote:

>Hello all,
>
>What is the best way to rearrange amplitude data in an FFT frame using
>pvs signal?
>
>I basically want to swap the amplitude data of one bin with another
>before synthesizing the FFT frame. So for instance to say that I want
>the amplitude of bin one to be swapped with the amplitude of bin 10
>and so on, but for every bin. I have tried pvsftw and vcopy but the
>result is very wobbly and not what I expected at all.
>
>The aim is to imitate the GRM tools spectral Warp. Is this possible?
>
>Many thanks in advance
>
>Best
>Peiman
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@... with body
>"unsubscribe csound"
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

David Mooney:  dmooney@...
Maxine Heller:  mheller@...
Opaque Melodies:  www.city-net.com/~moko/



Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[peiman]

Hello,

Using vcopy and pvsftw I managed it. Thanks to studying the UDO by
Matt Ingalls implementing spectral stretch. I have used his UDO as a
starting point and change the core of it to enable warping. I have
also changed the instrument to take stereo signal.

Using csound~ maxmsp external I am now able to change the warping
table in real-time.

I have attached the UDO + a csd file demonstrating it's use. Please
feel free to let me know if it works and what you think about it.

Best
Peiman


<CsoundSynthesizer>
<CsOptions>
</CsOptions>
<CsInstruments>

sr=44100
ksmps=10
nchnls=2



        opcode warp,0,iiiiii


inumbins, iampin, iampout, ifreqin, ifreqout, iwarp xin

; make sure we start with an empty table
iclear ftgen 0, 0, inumbins, 2, 0
        tablecopy iampout, iclear
        tablecopy ifreqout, iclear



kindex = 0

loop:


kind2 table   kindex, iwarp

vcopy  iampout, iampin, 1, kindex,kindex
vcopy  ifreqout, ifreqin, 1, kindex, kindex

vcopy  iampout, iampin, 1, kindex,kind2
vcopy  iampout, iampin, 1, kind2,kindex

vcopy  ifreqout, ifreqin, 1, kindex, kind2
vcopy  ifreqout, ifreqin, 1, kind2, kindex

kindex = kindex + 1

if (kindex < inumbins) kgoto loop

        endop
       
instr 1

;midi control
kdry invalue "dry"
kdry port kdry, 0.01

kwet invalue "wet"
kwet port kwet, 0.01
;;;;;;;;;;;;;;;;

ain1, ain2 ins ;;;input, can be changed with a soundfile

; get input and do pvanal
ifftsize = p4
iol = p5
iNumBins = ifftsize/2 + 1



fsigl pvsanal ain1, ifftsize, ifftsize/iol, ifftsize*4, 1
fsig2 pvsanal ain2, ifftsize, ifftsize/iol, ifftsize*4, 1
; [ or alternatively use pvsfread with a pvoc-ex file here ]
fsig3 pvsanal ain1, ifftsize, ifftsize/iol, ifftsize*4, 1
fsig4 pvsanal ain2, ifftsize, ifftsize/iol, ifftsize*4, 1

iwarp ftgen 0,0,iNumBins,-7,0,iNumBins, iNumBins ;warping table UNTOUCHED
;this should be modified for warping effects

iampin ftgen 0,0,iNumBins,2,0
iampout ftgen 0,0,iNumBins,2,0
ifreqin ftgen 0,0,iNumBins,2,0
ifreqout ftgen 0,0,iNumBins,2,0

iampin2 ftgen 0,0,iNumBins,2,0
iampout2 ftgen 0,0,iNumBins,2,0
ifreqin2 ftgen 0,0,iNumBins,2,0
ifreqout2 ftgen 0,0,iNumBins,2,0

; export fsig to tables
kflag pvsftw fsigl, iampin, ifreqin
if (kflag > 0) then ; only proc when frame is ready

;warp
        warp iNumBins, iampin, iampout, ifreqin, ifreqout, iwarp

; read modified data back to fsrc
        pvsftr fsigl, iampout, ifreqout

endif


; export fsig to tables
kflag2 pvsftw fsig2, iampin2, ifreqin2
if (kflag2 > 0) then ; only proc when frame is ready

; warp
        warp iNumBins, iampin2, iampout2, ifreqin2, ifreqout2, iwarp

; read modified data back to fsrc
        pvsftr fsig2, iampout2, ifreqout2

endif

; resynthesize and output - compare with untouched right channel


aout1 pvsynth fsigl
aout2 pvsynth fsig2

aout3 pvsynth fsig3
aout4 pvsynth fsig4

outs (aout1*kwet)+(aout3*kdry), (aout2*kwet)+(aout4*kdry)

endin


       
       
</CsInstruments>
<CsScore>

f0 86400

i2 0 -1 2048 8

e

</CsScore>
</CsoundSynthesizer>






2009/3/4 David Mooney/Maxine Heller <moko@...>:

> Similarly, I've attempted to use vpvoc and tableseg for spectral warping
> operations, but this does not seem to work (using the example in the Csound
> Book as a test using a file created with pvanal. The file works fine with
> pvoc). Before spending more time on this, am I recalling correctly that
> there is some problem with vpvoc in 5.x? Is there something else Peiman and
> I should be using?
>
> Thanks--
>
> --David
>
> At 09:15 AM 3/2/2009, you wrote:
>>
>> Hello all,
>>
>> What is the best way to rearrange amplitude data in an FFT frame using
>> pvs signal?
>>
>> I basically want to swap the amplitude data of one bin with another
>> before synthesizing the FFT frame. So for instance to say that I want
>> the amplitude of bin one to be swapped with the amplitude of bin 10
>> and so on, but for every bin. I have tried pvsftw and vcopy but the
>> result is very wobbly and not what I expected at all.
>>
>> The aim is to imitate the GRM tools spectral Warp. Is this possible?
>>
>> Many thanks in advance
>>
>> Best
>> Peiman
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>
> David Mooney:  dmooney@...
> Maxine Heller:  mheller@...
> Opaque Melodies:  www.city-net.com/~moko/
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"
>

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[peiman]

Hi Victor and all,

Am I right to think that if you read the pvs signal into tables and
then simply multiplied the freq table values with a constant you
wouldn't end up with a transposer? But why is this the case?

Thanks in advance
Peiman

2009/3/4 peiman khosravi <peimankhosravi@...>:

> Hello,
>
> Using vcopy and pvsftw I managed it. Thanks to studying the UDO by
> Matt Ingalls implementing spectral stretch. I have used his UDO as a
> starting point and change the core of it to enable warping. I have
> also changed the instrument to take stereo signal.
>
> Using csound~ maxmsp external I am now able to change the warping
> table in real-time.
>
> I have attached the UDO + a csd file demonstrating it's use. Please
> feel free to let me know if it works and what you think about it.
>
> Best
> Peiman
>
>
> <CsoundSynthesizer>
> <CsOptions>
> </CsOptions>
> <CsInstruments>
>
> sr=44100
> ksmps=10
> nchnls=2
>
>
>
>        opcode warp,0,iiiiii
>
>
> inumbins, iampin, iampout, ifreqin, ifreqout, iwarp xin
>
> ; make sure we start with an empty table
> iclear  ftgen 0, 0, inumbins, 2, 0
>        tablecopy iampout, iclear
>        tablecopy ifreqout, iclear
>
>
>
> kindex = 0
>
> loop:
>
>
> kind2   table   kindex, iwarp
>
> vcopy  iampout, iampin, 1, kindex,kindex
> vcopy  ifreqout, ifreqin, 1, kindex, kindex
>
> vcopy  iampout, iampin, 1, kindex,kind2
> vcopy  iampout, iampin, 1, kind2,kindex
>
> vcopy  ifreqout, ifreqin, 1, kindex, kind2
> vcopy  ifreqout, ifreqin, 1, kind2, kindex
>
> kindex = kindex + 1
>
> if (kindex < inumbins) kgoto loop
>
>        endop
>
> instr 1
>
> ;midi control
> kdry    invalue "dry"
> kdry    port kdry, 0.01
>
> kwet    invalue "wet"
> kwet    port kwet, 0.01
> ;;;;;;;;;;;;;;;;
>
> ain1, ain2      ins ;;;input, can be changed with a soundfile
>
> ; get input and do pvanal
> ifftsize = p4
> iol = p5
> iNumBins = ifftsize/2 + 1
>
>
>
> fsigl pvsanal ain1, ifftsize, ifftsize/iol, ifftsize*4, 1
> fsig2 pvsanal ain2, ifftsize, ifftsize/iol, ifftsize*4, 1
> ; [ or alternatively use pvsfread with a pvoc-ex file here ]
> fsig3 pvsanal ain1, ifftsize, ifftsize/iol, ifftsize*4, 1
> fsig4 pvsanal ain2, ifftsize, ifftsize/iol, ifftsize*4, 1
>
> iwarp   ftgen 0,0,iNumBins,-7,0,iNumBins, iNumBins ;warping table UNTOUCHED
> ;this should be modified for warping effects
>
> iampin ftgen 0,0,iNumBins,2,0
> iampout ftgen 0,0,iNumBins,2,0
> ifreqin ftgen 0,0,iNumBins,2,0
> ifreqout ftgen 0,0,iNumBins,2,0
>
> iampin2 ftgen 0,0,iNumBins,2,0
> iampout2 ftgen 0,0,iNumBins,2,0
> ifreqin2 ftgen 0,0,iNumBins,2,0
> ifreqout2 ftgen 0,0,iNumBins,2,0
>
> ; export fsig to tables
> kflag pvsftw fsigl, iampin, ifreqin
> if (kflag > 0) then ; only proc when frame is ready
>
> ;warp
>        warp iNumBins, iampin, iampout, ifreqin, ifreqout, iwarp
>
> ; read modified data back to fsrc
>        pvsftr fsigl, iampout, ifreqout
>
> endif
>
>
> ; export fsig to tables
> kflag2 pvsftw fsig2, iampin2, ifreqin2
> if (kflag2 > 0) then ; only proc when frame is ready
>
> ; warp
>        warp iNumBins, iampin2, iampout2, ifreqin2, ifreqout2, iwarp
>
> ; read modified data back to fsrc
>        pvsftr fsig2, iampout2, ifreqout2
>
> endif
>
> ; resynthesize and output - compare with untouched right channel
>
>
> aout1 pvsynth fsigl
> aout2 pvsynth fsig2
>
> aout3 pvsynth fsig3
> aout4 pvsynth fsig4
>
> outs (aout1*kwet)+(aout3*kdry), (aout2*kwet)+(aout4*kdry)
>
> endin
>
>
>
>
> </CsInstruments>
> <CsScore>
>
> f0 86400
>
> i2 0 -1 2048 8
>
> e
>
> </CsScore>
> </CsoundSynthesizer>
>
>
>
>
>
>
> 2009/3/4 David Mooney/Maxine Heller <moko@...>:
>> Similarly, I've attempted to use vpvoc and tableseg for spectral warping
>> operations, but this does not seem to work (using the example in the Csound
>> Book as a test using a file created with pvanal. The file works fine with
>> pvoc). Before spending more time on this, am I recalling correctly that
>> there is some problem with vpvoc in 5.x? Is there something else Peiman and
>> I should be using?
>>
>> Thanks--
>>
>> --David
>>
>> At 09:15 AM 3/2/2009, you wrote:
>>>
>>> Hello all,
>>>
>>> What is the best way to rearrange amplitude data in an FFT frame using
>>> pvs signal?
>>>
>>> I basically want to swap the amplitude data of one bin with another
>>> before synthesizing the FFT frame. So for instance to say that I want
>>> the amplitude of bin one to be swapped with the amplitude of bin 10
>>> and so on, but for every bin. I have tried pvsftw and vcopy but the
>>> result is very wobbly and not what I expected at all.
>>>
>>> The aim is to imitate the GRM tools spectral Warp. Is this possible?
>>>
>>> Many thanks in advance
>>>
>>> Best
>>> Peiman
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@... with body "unsubscribe
>>> csound"
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>
>> David Mooney:  dmooney@...
>> Maxine Heller:  mheller@...
>> Opaque Melodies:  www.city-net.com/~moko/
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>>
>

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Victor Lazzarini]

yes, you are (unless you are using the sliding version or doing
additive synthesis). In a simple
explanation, that is because each bin has a limit to what frequencies
it can represent (a range), if you go above or below it, you will
'wrap-around'.

However, that is only the case for overlap-add IDFT-type resynthesis.
With additive synthesis in theory you can do whatever you want w
with the frequencies, since you are driving a bank of oscillators.

Victor

----- Original Message -----
From: "peiman khosravi" <peimankhosravi@...>
To: <csound@...>
Sent: Thursday, March 05, 2009 10:07 AM
Subject: [Csnd] Re: Re: pvs and spectral warping (as in GRM tools)


Hi Victor and all,

Am I right to think that if you read the pvs signal into tables and
then simply multiplied the freq table values with a constant you
wouldn't end up with a transposer? But why is this the case?

Thanks in advance
Peiman

2009/3/4 peiman khosravi <peimankhosravi@...>:

> Hello,
>
> Using vcopy and pvsftw I managed it. Thanks to studying the UDO by
> Matt Ingalls implementing spectral stretch. I have used his UDO as a
> starting point and change the core of it to enable warping. I have
> also changed the instrument to take stereo signal.
>
> Using csound~ maxmsp external I am now able to change the warping
> table in real-time.
>
> I have attached the UDO + a csd file demonstrating it's use. Please
> feel free to let me know if it works and what you think about it.
>
> Best
> Peiman
>
>
> <CsoundSynthesizer>
> <CsOptions>
> </CsOptions>
> <CsInstruments>
>
> sr=44100
> ksmps=10
> nchnls=2
>
>
>
> opcode warp,0,iiiiii
>
>
> inumbins, iampin, iampout, ifreqin, ifreqout, iwarp xin
>
> ; make sure we start with an empty table
> iclear ftgen 0, 0, inumbins, 2, 0
> tablecopy iampout, iclear
> tablecopy ifreqout, iclear
>
>
>
> kindex = 0
>
> loop:
>
>
> kind2 table kindex, iwarp
>
> vcopy iampout, iampin, 1, kindex,kindex
> vcopy ifreqout, ifreqin, 1, kindex, kindex
>
> vcopy iampout, iampin, 1, kindex,kind2
> vcopy iampout, iampin, 1, kind2,kindex
>
> vcopy ifreqout, ifreqin, 1, kindex, kind2
> vcopy ifreqout, ifreqin, 1, kind2, kindex
>
> kindex = kindex + 1
>
> if (kindex < inumbins) kgoto loop
>
> endop
>
> instr 1
>
> ;midi control
> kdry invalue "dry"
> kdry port kdry, 0.01
>
> kwet invalue "wet"
> kwet port kwet, 0.01
> ;;;;;;;;;;;;;;;;
>
> ain1, ain2 ins ;;;input, can be changed with a soundfile
>
> ; get input and do pvanal
> ifftsize = p4
> iol = p5
> iNumBins = ifftsize/2 + 1
>
>
>
> fsigl pvsanal ain1, ifftsize, ifftsize/iol, ifftsize*4, 1
> fsig2 pvsanal ain2, ifftsize, ifftsize/iol, ifftsize*4, 1
> ; [ or alternatively use pvsfread with a pvoc-ex file here ]
> fsig3 pvsanal ain1, ifftsize, ifftsize/iol, ifftsize*4, 1
> fsig4 pvsanal ain2, ifftsize, ifftsize/iol, ifftsize*4, 1
>
> iwarp ftgen 0,0,iNumBins,-7,0,iNumBins, iNumBins ;warping table UNTOUCHED
> ;this should be modified for warping effects
>
> iampin ftgen 0,0,iNumBins,2,0
> iampout ftgen 0,0,iNumBins,2,0
> ifreqin ftgen 0,0,iNumBins,2,0
> ifreqout ftgen 0,0,iNumBins,2,0
>
> iampin2 ftgen 0,0,iNumBins,2,0
> iampout2 ftgen 0,0,iNumBins,2,0
> ifreqin2 ftgen 0,0,iNumBins,2,0
> ifreqout2 ftgen 0,0,iNumBins,2,0
>
> ; export fsig to tables
> kflag pvsftw fsigl, iampin, ifreqin
> if (kflag > 0) then ; only proc when frame is ready
>
> ;warp
> warp iNumBins, iampin, iampout, ifreqin, ifreqout, iwarp
>
> ; read modified data back to fsrc
> pvsftr fsigl, iampout, ifreqout
>
> endif
>
>
> ; export fsig to tables
> kflag2 pvsftw fsig2, iampin2, ifreqin2
> if (kflag2 > 0) then ; only proc when frame is ready
>
> ; warp
> warp iNumBins, iampin2, iampout2, ifreqin2, ifreqout2, iwarp
>
> ; read modified data back to fsrc
> pvsftr fsig2, iampout2, ifreqout2
>
> endif
>
> ; resynthesize and output - compare with untouched right channel
>
>
> aout1 pvsynth fsigl
> aout2 pvsynth fsig2
>
> aout3 pvsynth fsig3
> aout4 pvsynth fsig4
>
> outs (aout1*kwet)+(aout3*kdry), (aout2*kwet)+(aout4*kdry)
>
> endin
>
>
>
>
> </CsInstruments>
> <CsScore>
>
> f0 86400
>
> i2 0 -1 2048 8
>
> e
>
> </CsScore>
> </CsoundSynthesizer>
>
>
>
>
>
>
> 2009/3/4 David Mooney/Maxine Heller <moko@...>:
>> Similarly, I've attempted to use vpvoc and tableseg for spectral warping
>> operations, but this does not seem to work (using the example in the
>> Csound
>> Book as a test using a file created with pvanal. The file works fine with
>> pvoc). Before spending more time on this, am I recalling correctly that
>> there is some problem with vpvoc in 5.x? Is there something else Peiman
>> and
>> I should be using?
>>
>> Thanks--
>>
>> --David
>>
>> At 09:15 AM 3/2/2009, you wrote:
>>>
>>> Hello all,
>>>
>>> What is the best way to rearrange amplitude data in an FFT frame using
>>> pvs signal?
>>>
>>> I basically want to swap the amplitude data of one bin with another
>>> before synthesizing the FFT frame. So for instance to say that I want
>>> the amplitude of bin one to be swapped with the amplitude of bin 10
>>> and so on, but for every bin. I have tried pvsftw and vcopy but the
>>> result is very wobbly and not what I expected at all.
>>>
>>> The aim is to imitate the GRM tools spectral Warp. Is this possible?
>>>
>>> Many thanks in advance
>>>
>>> Best
>>> Peiman
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@... with body "unsubscribe
>>> csound"
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>
>> David Mooney: dmooney@...
>> Maxine Heller: mheller@...
>> Opaque Melodies: www.city-net.com/~moko/
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>>
>

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe
csound"=



Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[richarddobson]

With the SDFT (hopsize = 1) you can indeed just do that, as the
bandwidth of each bin is the whole frequency range. All you have to
worry about is Nyquist. This is what makes Transformational FM
arithmetically easy, as all bins can be treated as if they are simple
additive sinusoids (and resynthsis is by oscillator bank).

With the normal "hopping" pvoc it is not as simple - the relatively
large hops reduce the bandwidth of a bin significantly, so that when you
rescale a given bin frequency, it may exceed that bandwidth and
therefore have to be put into a higher or lower bin. That is, if you
want the speed of FFT resynthesis. Many versions of Pvoc (e.g. the one
in the F.R. Moore book and in the "PVNation" distribution) automatically
go to oscillator bank resynthesis when any pitch scaling is done. So if
you want to try the simple rescaling approach, without the massive
overhead of the SDFT, make sure you use pvsadsyn or one of Victor's
tracking-based additive opcodes.

With SDFT you still have to worry about phasing effects**, it is not a
"free lunch" solution, but it is possible at least some of the solutions
are easier. This is all very much work in progress!


** The basic issue is  that when a partial is "resolved" by pvoc
analysis, multiple adjacent bins receive virtually identical frequency
values - the bins are bunched together  (see the figs in our SPV paper
for ICMC 2007). If you just multiply these, the differences  between
them (Hz) change; in the worst case, what was one partial gets split
into many.  You have to shift them as a group (this is a description
therefore of "Phase-locking").  For clearly distinguished components in
a pitched tone this is relatively easy (but you have to work out the
correct shift amount for each bunch); for percussive and noise-based
sounds rather less easy!

Richard Dobson




peiman khosravi wrote:
> Hi Victor and all,
>
> Am I right to think that if you read the pvs signal into tables and
> then simply multiplied the freq table values with a constant you
> wouldn't end up with a transposer? But why is this the case?
>
> Thanks in advance
> Peiman
>



Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[peiman]

Thank you very much for the thorough explanation. Very helpful.

Best
Peiman

2009/3/5 Richard Dobson <richarddobson@...>:

> With the SDFT (hopsize = 1) you can indeed just do that, as the bandwidth of
> each bin is the whole frequency range. All you have to worry about is
> Nyquist. This is what makes Transformational FM arithmetically easy, as all
> bins can be treated as if they are simple additive sinusoids (and resynthsis
> is by oscillator bank).
>
> With the normal "hopping" pvoc it is not as simple - the relatively large
> hops reduce the bandwidth of a bin significantly, so that when you rescale a
> given bin frequency, it may exceed that bandwidth and therefore have to be
> put into a higher or lower bin. That is, if you want the speed of FFT
> resynthesis. Many versions of Pvoc (e.g. the one in the F.R. Moore book and
> in the "PVNation" distribution) automatically go to oscillator bank
> resynthesis when any pitch scaling is done. So if you want to try the simple
> rescaling approach, without the massive overhead of the SDFT, make sure you
> use pvsadsyn or one of Victor's tracking-based additive opcodes.
>
> With SDFT you still have to worry about phasing effects**, it is not a "free
> lunch" solution, but it is possible at least some of the solutions are
> easier. This is all very much work in progress!
>
>
> ** The basic issue is  that when a partial is "resolved" by pvoc analysis,
> multiple adjacent bins receive virtually identical frequency values - the
> bins are bunched together  (see the figs in our SPV paper for ICMC 2007). If
> you just multiply these, the differences  between them (Hz) change; in the
> worst case, what was one partial gets split into many.  You have to shift
> them as a group (this is a description therefore of "Phase-locking").  For
> clearly distinguished components in a pitched tone this is relatively easy
> (but you have to work out the correct shift amount for each bunch); for
> percussive and noise-based sounds rather less easy!
>
> Richard Dobson
>
>
>
>
> peiman khosravi wrote:
>>
>> Hi Victor and all,
>>
>> Am I right to think that if you read the pvs signal into tables and
>> then simply multiplied the freq table values with a constant you
>> wouldn't end up with a transposer? But why is this the case?
>>
>> Thanks in advance
>> Peiman
>>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"
>

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[peiman]

Sorry for resurrecting a dead thread!

Come to think of it I am afraid there is just one thing I'm not quite getting here.

I understand that the frequency data will wrap-around is it exceeds the bandwidth assigned to it. Now what will happen if the frequency of a bin is copied from one bin to another? Will the frequency be be automatically shifted to fit the bandwidth of the new bin? Will this retain the internal jitter structure of the original bin but at a lower or higher frequency?

Also

in his spectral stretching UDO Matt Ingalls has this loop block which really baffles me.


kcount = 0
loop:
kindex = kcount/kpitch

if (kindex < inumbins) then
kval table kindex, iampin
kamp table kcount, iampout
        tablew kval+kamp, kcount, iampout

kval table kindex, ifreqin
        tablew kval*kpitch, kcount, ifreqout
endif

kcount = kcount + 1
kpitch = kpitch * kstretch

if (kcount < inumbins) kgoto loop



Why is the freq data being multiplied (theoretically this shouldn't work right? unless one uses an oscillator bank for re-synthesis but the code works with pvsynth and I can't work out why!) and why is the amplitude data being altered in this way (kval+kamp)? Is this some sort of a trick to shift the bins?

I am curious about these things as I am modeling the GRM tools frequency warping effect in csound and want to know why their plug-in destroys the phase of the signal. This hints that they are somehow altering the frequency data as well as the amplitude, but why? Isn't it sufficient to just exchange the amp of the input bin with the output bin and use the original frequency data?

Thanks and apologies for all these questions!

Best
Peiman

peiman wrote:

Thank you very much for the thorough explanation. Very helpful.

Best
Peiman

2009/3/5 Richard Dobson <[e-mail]>:
> With the SDFT (hopsize = 1) you can indeed just do that, as the bandwidth of
> each bin is the whole frequency range. All you have to worry about is
> Nyquist. This is what makes Transformational FM arithmetically easy, as all
> bins can be treated as if they are simple additive sinusoids (and resynthsis
> is by oscillator bank).
>
> With the normal "hopping" pvoc it is not as simple - the relatively large
> hops reduce the bandwidth of a bin significantly, so that when you rescale a
> given bin frequency, it may exceed that bandwidth and therefore have to be
> put into a higher or lower bin. That is, if you want the speed of FFT
> resynthesis. Many versions of Pvoc (e.g. the one in the F.R. Moore book and
> in the "PVNation" distribution) automatically go to oscillator bank
> resynthesis when any pitch scaling is done. So if you want to try the simple
> rescaling approach, without the massive overhead of the SDFT, make sure you
> use pvsadsyn or one of Victor's tracking-based additive opcodes.
>
> With SDFT you still have to worry about phasing effects**, it is not a "free
> lunch" solution, but it is possible at least some of the solutions are
> easier. This is all very much work in progress!
>
>
> ** The basic issue is  that when a partial is "resolved" by pvoc analysis,
> multiple adjacent bins receive virtually identical frequency values - the
> bins are bunched together  (see the figs in our SPV paper for ICMC 2007). If
> you just multiply these, the differences  between them (Hz) change; in the
> worst case, what was one partial gets split into many.  You have to shift
> them as a group (this is a description therefore of "Phase-locking").  For
> clearly distinguished components in a pitched tone this is relatively easy
> (but you have to work out the correct shift amount for each bunch); for
> percussive and noise-based sounds rather less easy!
>
> Richard Dobson
>
>
>
>
> peiman khosravi wrote:
>>
>> Hi Victor and all,
>>
>> Am I right to think that if you read the pvs signal into tables and
>> then simply multiplied the freq table values with a constant you
>> wouldn't end up with a transposer? But why is this the case?
>>
>> Thanks in advance
>> Peiman
>>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email [e-mail] with body "unsubscribe
> csound"
>


Send bugs reports to this list.
To unsubscribe, send email [e-mail] with body "unsubscribe csound"

[richarddobson]

peiman wrote:

> Sorry for resurrecting a dead thread!
>
> Come to think of it I am afraid there is just one thing I'm not quite
> getting here.
>
> I understand that the frequency data will wrap-around is it exceeds the
> bandwidth assigned to it. Now what will happen if the frequency of a bin is
> copied from one bin to another? Will the frequency be be automatically
> shifted to fit the bandwidth of the new bin? Will this retain the internal
> jitter structure of the original bin but at a lower or higher frequency?
>

It's slightly the wrong question. It is the programmer's job to work out
how to map a transformed frequency to an appropriate bin. Which is what
Matt's code does, among other things...


> Also
>
> in his spectral stretching UDO Matt Ingalls has this loop block which really
> baffles me.
..
>
> Why is the freq data being multiplied (theoretically this shouldn't work
> right?


Any pitch shift/stretch/warp necessarily scales frequencies by some
factor; then the new frequencies have to be slotted into an appropriate
bin. Some algorithms will multiply; others may add (to get wild+crazy
inharmonic effects etc).

unless one uses an oscillator bank for re-synthesis but the code
> works with pvsynth and I can't work out why!) and why is the amplitude data
> being altered in this way (kval+kamp)? Is this some sort of a trick to shift
> the bins?
>


The model of "stretching" a whole spectrum is of printing the spectrum
on a rubber band and then stretching it. ~Everything~ stretches: both
the frequencies and the amplitudes.

> I am curious about these things as I am modeling the GRM tools frequency
> warping effect in csound and want to know why their plug-in destroys the
> phase of the signal. This hints that they are somehow altering the frequency
> data as well as the amplitude, but why? Isn't it sufficient to just exchange
> the amp of the input bin with the output bin and use the original frequency
> data?
>

Any frequency modification (in pvoc) suffers this (side-)effect.
Frequency warping means doing that, by definition. Transferring just
amplitudes is what opcodes such as pvscross do - cross-synthesis or
hybridisation.


It is a moot point indeed whether this should even be regarded as a side
effect. It is a bit like time-domain stretching: in principle, attacks
get stretched along with everything else; but composers sometimes would
like to keep them as tight as possible, so they come up with tricks to
stretch only the pitched part of the sound. When you warp/stretch a
whole spectrum, what result are you imagining for that process before
you start? It is something other than pure transposition or resampling.
The problem we have is that in the frequency domain the "tricks" are not
so obvious.  Kind of reassuring to know, in a way, that even the adepts
at GRM have not solved the phase problem!

Richard Dobson



Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[peiman]

Thanks very much for this. It is slowly beginning to click!

I understand that the frequency data will wrap-around is it exceeds the
bandwidth assigned to it. Now what will happen if the frequency of a bin is
copied from one bin to another? Will the frequency be be automatically
shifted to fit the bandwidth of the new bin? Will this retain the internal
jitter structure of the original bin but at a lower or higher frequency?

It's slightly the wrong question. It is the programmer's job to work out how to map a transformed frequency to an appropriate bin. Which is what Matt's code does, among other things...

By this I meant actually using the vcopy opcode to literally remap the frequency table entry's from one tableto another but at a different indext. What effect would this have on the fsignal? Would this shift the source frequency to fit the destination bin? Say if you copy the 100th bin of table one to the 10th bin of table two.

I am imagining a situation where you can shift the individual bins separately, using a warping function table.

The problem is this: warping the amplitude data is easy as it simply means taking the input bins and recursively adding it to the output table. So for instance the amplitude of bin 10 is added to bin 2 of a second (initially zeroed) table, then bin 13 is also added to bin 2 of the second table (no longer zeroed) and amplitude of bin 20 is added to bin 5 and so on.   

Now I could take this newly achieved table and couple it with the original frequency table of the signal. This seems to work well for transient and noisy sounds as the phase is retained.

However I suspect as you mention in a classic warping effect the frequency data has to be fiddled with as well. But how? Adding them in the same way wouldn't make sense. Taking the first example, it wouldn't make sense to do this:

The frequency of bin 10 is added to bin 2 of an initially zeroed second table, and so on. 

Replacing the frequency data with the old one also wouldn't make sense: if two bins are copied to the same destination bin then only one can stay! So the question is how to shift the frequency bins.

You can tell I'm a bit confused!!

Thanks again
Peiman

2009/7/8 Richard Dobson <richarddobson@...>

peiman wrote:

Sorry for resurrecting a dead thread!
Come to think of it I am afraid there is just one thing I'm not quite
getting here.

I understand that the frequency data will wrap-around is it exceeds the
bandwidth assigned to it. Now what will happen if the frequency of a bin is
copied from one bin to another? Will the frequency be be automatically
shifted to fit the bandwidth of the new bin? Will this retain the internal
jitter structure of the original bin but at a lower or higher frequency?

It's slightly the wrong question. It is the programmer's job to work out how to map a transformed frequency to an appropriate bin. Which is what Matt's code does, among other things...

Also

in his spectral stretching UDO Matt Ingalls has this loop block which really
baffles me.

..

Why is the freq data being multiplied (theoretically this shouldn't work
right?

Any pitch shift/stretch/warp necessarily scales frequencies by some factor; then the new frequencies have to be slotted into an appropriate bin. Some algorithms will multiply; others may add (to get wild+crazy inharmonic effects etc).

unless one uses an oscillator bank for re-synthesis but the code

works with pvsynth and I can't work out why!) and why is the amplitude data
being altered in this way (kval+kamp)? Is this some sort of a trick to shift
the bins?

The model of "stretching" a whole spectrum is of printing the spectrum on a rubber band and then stretching it. ~Everything~ stretches: both the frequencies and the amplitudes.

I am curious about these things as I am modeling the GRM tools frequency
warping effect in csound and want to know why their plug-in destroys the
phase of the signal. This hints that they are somehow altering the frequency
data as well as the amplitude, but why? Isn't it sufficient to just exchange
the amp of the input bin with the output bin and use the original frequency
data?

Any frequency modification (in pvoc) suffers this (side-)effect. Frequency warping means doing that, by definition. Transferring just amplitudes is what opcodes such as pvscross do - cross-synthesis or hybridisation.


It is a moot point indeed whether this should even be regarded as a side effect. It is a bit like time-domain stretching: in principle, attacks get stretched along with everything else; but composers sometimes would like to keep them as tight as possible, so they come up with tricks to stretch only the pitched part of the sound. When you warp/stretch a whole spectrum, what result are you imagining for that process before you start? It is something other than pure transposition or resampling. The problem we have is that in the frequency domain the "tricks" are not so obvious.  Kind of reassuring to know, in a way, that even the adepts at GRM have not solved the phase problem!

Richard Dobson

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[richarddobson]

I regret that I can't spend a lot of time on these questions just now
(got deadlines to meet...)


peiman khosravi wrote:
..
> By this I meant actually using the vcopy opcode to literally remap the
> frequency table entry's from one tableto another but at a different
> indext. What effect would this have on the fsignal? Would this shift the
> source frequency to fit the destination bin? Say if you copy the 100th
> bin of table one to the 10th bin of table two.
>

That sounds like an extreme move! Expect artifacts. With large downward
shifts (or whatever we call them), multiple HF bin data may have to
descend into the same lower bin; accuracy is by definition being
reduced. An FFT gives you a "sampled" spectrum, and either you are
interpolating (which doesn't really get you any ~new~ information) or
decimating, in which case you definitely will lose some information.


> I am imagining a situation where you can shift the individual bins
> separately, using a warping function table.
>

You can use any methodology you like (this is after all an artistic
exercise at least as much as it is a technical one - one person's "warp"
is another person's "stretch", etc). The only "rule" with pvoc is that
if the frequency in a bin is modified so that it falls outside the
limits for that bin, the sine and cosine calcs will wrap it into the
range in a way that is probably unintended. Beyond that, you can put
whatever you like in any bin - the issue is then an artistic one of what
you are trying to do (precisely), and how much by way of artefacts and
the unexpected you are prepared to accept. But things like frequency
warping (as I understand that term, amyway) are so off the wall, there
is no mainstream linear dsp process it corresponds to. If it does what
you want (or like) - it works.


..
> However I suspect as you mention in a classic warping effect the
> frequency data has to be fiddled with as well. But how? Adding them in
> the same way wouldn't make sense. Taking the first example, it wouldn't
> make sense to do this:
>
..


The principle most often applied (AFAIK) is that of masking - the
dominant bin frequency (e.g. the loudest) goes into the new bin.
Otherwise, you may as well take an average. Think of what you would see
if you took an FFT of a  waveform (a sawtooth, say) , and an FFT of
another of substantially lower pitch. You then consider how you would
map the bins of the former to the latter. Work it out with pencil and
paper if need be. In the former, maybe 30 bins cover one partial; in the
latter, only 4 or 5 (worst case, barely more than one!). You take the
(frequency) envelope over N bins, and as it were resample that envelope
to obtain the N/5 bin values you need. In this case you are not "moving"
bins, you are calculating new ones, from old data.  Different effects
very probably, in each case - but only you can say what you want the
result to be. Note you can use pvsadsyn (etc) to test the effects of
your manuipulations, and later on recast it with whatever bin
adjustments are needed to make pvsynth work as well.

Basically, these are all legitimate research questions (there is almost
certainly no one single correct answer because these effects are not
rigorously defined, there may be 1001 variations) - try it and see! the
computer won't blow up, and the sky won't fall in...

Richard Dobson




Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[peiman]

Thanks very much,

I will carry an experiment using your suggestion regarding the masking. I'll post the result here soon!

Best
Peiman

2009/7/9 Richard Dobson <richarddobson@...>

I regret that I can't spend a lot of time on these questions just now (got deadlines to meet...)

peiman khosravi wrote:
..

By this I meant actually using the vcopy opcode to literally remap the frequency table entry's from one tableto another but at a different indext. What effect would this have on the fsignal? Would this shift the source frequency to fit the destination bin? Say if you copy the 100th bin of table one to the 10th bin of table two.

That sounds like an extreme move! Expect artifacts. With large downward shifts (or whatever we call them), multiple HF bin data may have to descend into the same lower bin; accuracy is by definition being reduced. An FFT gives you a "sampled" spectrum, and either you are interpolating (which doesn't really get you any ~new~ information) or decimating, in which case you definitely will lose some information.

I am imagining a situation where you can shift the individual bins separately, using a warping function table.

You can use any methodology you like (this is after all an artistic exercise at least as much as it is a technical one - one person's "warp" is another person's "stretch", etc). The only "rule" with pvoc is that if the frequency in a bin is modified so that it falls outside the limits for that bin, the sine and cosine calcs will wrap it into the range in a way that is probably unintended. Beyond that, you can put whatever you like in any bin - the issue is then an artistic one of what you are trying to do (precisely), and how much by way of artefacts and the unexpected you are prepared to accept. But things like frequency warping (as I understand that term, amyway) are so off the wall, there is no mainstream linear dsp process it corresponds to. If it does what you want (or like) - it works.


..

However I suspect as you mention in a classic warping effect the frequency data has to be fiddled with as well. But how? Adding them in the same way wouldn't make sense. Taking the first example, it wouldn't make sense to do this:

..

The principle most often applied (AFAIK) is that of masking - the dominant bin frequency (e.g. the loudest) goes into the new bin. Otherwise, you may as well take an average. Think of what you would see if you took an FFT of a  waveform (a sawtooth, say) , and an FFT of another of substantially lower pitch. You then consider how you would map the bins of the former to the latter. Work it out with pencil and paper if need be. In the former, maybe 30 bins cover one partial; in the latter, only 4 or 5 (worst case, barely more than one!). You take the (frequency) envelope over N bins, and as it were resample that envelope to obtain the N/5 bin values you need. In this case you are not "moving" bins, you are calculating new ones, from old data.  Different effects very probably, in each case - but only you can say what you want the result to be. Note you can use pvsadsyn (etc) to test the effects of your manuipulations, and later on recast it with whatever bin adjustments are needed to make pvsynth work as well.

Basically, these are all legitimate research questions (there is almost certainly no one single correct answer because these effects are not rigorously defined, there may be 1001 variations) - try it and see! the computer won't blow up, and the sky won't fall in...

Richard Dobson




Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"