« Return to Thread: pvs and spectral warping (as in GRM tools)
Re: Re: Re: Re: pvs and spectral warping (as in GRM tools)
by peiman
::
Rate this Message:
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
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 <richarddobson@blueyonder.co.uk>:
> 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@lists.bath.ac.uk with body "unsubscribe
> csound"
>
Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
« Return to Thread: pvs and spectral warping (as in GRM tools)
| Free embeddable forum powered by Nabble | Forum Help |
