« Return to Thread: pvs and spectral warping (as in GRM tools)
Re: Re: Re: Re: Re: pvs and spectral warping (as in GRM tools)
by richarddobson
::
Rate this Message:
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"
> 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"
« Return to Thread: pvs and spectral warping (as in GRM tools)
| Free embeddable forum powered by Nabble | Forum Help |
