Dear all,

I've spend the last 2 hours experimenting with a PVS based UDO that
takes the fft bins and randomly distributes each bin to one of six
speakers upon each fft window pass. After this I pass the pvs signal
through pvsoomth to make the scattering of bins more diffused. The
result?? Pure joy! Importantly the individual speakers are not really
noticed even if you sit right next to them, the material is truly
diffused in the listening space. The speakers just sort of become
invisible! I would like to make different versions of this with more
controls and so on.

Has anyone experimented with similar things?? I'd be very interested
to hear about your experiences.

Best,

Peiman


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I have done a similar thing with frequency tracks with wavefield  
synthesis / ambisonics,
moving groups of tracks around. There was a paper a few years back at  
DAFx and
I think LAC, where they were doing a similar thing (http://www2.hsu-hh.de/ant/dafx2002/papers/DAFX02_Topper_Burtner_Serafin_SOS_synthesis.pdf 
  ),
moving spectral bands around.

Victor
On 16 Jan 2011, at 19:21, peiman khosravi wrote:

> Dear all,
>
> I've spend the last 2 hours experimenting with a PVS based UDO that
> takes the fft bins and randomly distributes each bin to one of six
> speakers upon each fft window pass. After this I pass the pvs signal
> through pvsoomth to make the scattering of bins more diffused. The
> result?? Pure joy! Importantly the individual speakers are not really
> noticed even if you sit right next to them, the material is truly
> diffused in the listening space. The speakers just sort of become
> invisible! I would like to make different versions of this with more
> controls and so on.
>
> Has anyone experimented with similar things?? I'd be very interested
> to hear about your experiences.
>
> Best,
>
> Peiman
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yes, but I never got to hear it properly!

I performed an additive synthesis of some sounds using a udo which read
prom a table produced by pvsftw. Did you do something like this?

I also found I could further process each partial independently to produce
some really interesting effects for example by modulating the frequency of
the partials at audio rate.

-Joel

On 16 January 2011 20:21, peiman khosravi  wrote:
> Dear all,
>
> I've spend the last 2 hours experimenting with a PVS based UDO that
> takes the fft bins and randomly distributes each bin to one of six
> speakers upon each fft window pass. After this I pass the pvs signal
> through pvsoomth to make the scattering of bins more diffused. The
> result?? Pure joy! Importantly the individual speakers are not really
> noticed even if you sit right next to them, the material is truly
> diffused in the listening space. The speakers just sort of become
> invisible! I would like to make different versions of this with more
> controls and so on.
>
> Has anyone experimented with similar things?? I'd be very interested
> to hear about your experiences.
>
> Best,
>
> Peiman
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks Victor,

I am going to read the paper, that's very interesting.

Peiman

On 16 January 2011 19:31, Victor Lazzarini  wrote:
> I have done a similar thing with frequency tracks with wavefield synthesis /
> ambisonics,
> moving groups of tracks around. There was a paper a few years back at DAFx
> and
> I think LAC, where they were doing a similar thing
> (http://www2.hsu-hh.de/ant/dafx2002/papers/DAFX02_Topper_Burtner_Serafin_SOS_synthesis.pdf
> ),
> moving spectral bands around.
>
> Victor
> On 16 Jan 2011, at 19:21, peiman khosravi wrote:
>
>> Dear all,
>>
>> I've spend the last 2 hours experimenting with a PVS based UDO that
>> takes the fft bins and randomly distributes each bin to one of six
>> speakers upon each fft window pass. After this I pass the pvs signal
>> through pvsoomth to make the scattering of bins more diffused. The
>> result?? Pure joy! Importantly the individual speakers are not really
>> noticed even if you sit right next to them, the material is truly
>> diffused in the listening space. The speakers just sort of become
>> invisible! I would like to make different versions of this with more
>> controls and so on.
>>
>> Has anyone experimented with similar things?? I'd be very interested
>> to hear about your experiences.
>>
>> Best,
>>
>> Peiman
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yes exactly. How did you modulate each partial? Where you using
partial tracking or straight FFT?

Interestingly certain sound extremely elevated when processed in this
way (I mean literary overhead).

Thanks

Peiman

On 16 January 2011 19:32, Joel Ross  wrote:
> Yes, but I never got to hear it properly!
>
> I performed an additive synthesis of some sounds using a udo which read
> prom a table produced by pvsftw. Did you do something like this?
>
> I also found I could further process each partial independently to produce
> some really interesting effects for example by modulating the frequency of
> the partials at audio rate.
>
> -Joel
>
> On 16 January 2011 20:21, peiman khosravi  wrote:
>> Dear all,
>>
>> I've spend the last 2 hours experimenting with a PVS based UDO that
>> takes the fft bins and randomly distributes each bin to one of six
>> speakers upon each fft window pass. After this I pass the pvs signal
>> through pvsoomth to make the scattering of bins more diffused. The
>> result?? Pure joy! Importantly the individual speakers are not really
>> noticed even if you sit right next to them, the material is truly
>> diffused in the listening space. The speakers just sort of become
>> invisible! I would like to make different versions of this with more
>> controls and so on.
>>
>> Has anyone experimented with similar things?? I'd be very interested
>> to hear about your experiences.
>>
>> Best,
>>
>> Peiman
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

does the processing alter the timbral characteristics of the sound. I  
am wondering because
you mentioned using pvsmooth.

Victor
On 16 Jan 2011, at 19:44, peiman khosravi wrote:

> Yes exactly. How did you modulate each partial? Where you using
> partial tracking or straight FFT?
>
> Interestingly certain sound extremely elevated when processed in this
> way (I mean literary overhead).
>
> Thanks
>
> Peiman
>
> On 16 January 2011 19:32, Joel Ross   
> wrote:
>> Yes, but I never got to hear it properly!
>>
>> I performed an additive synthesis of some sounds using a udo which  
>> read
>> prom a table produced by pvsftw. Did you do something like this?
>>
>> I also found I could further process each partial independently to  
>> produce
>> some really interesting effects for example by modulating the  
>> frequency of
>> the partials at audio rate.
>>
>> -Joel
>>
>> On 16 January 2011 20:21, peiman khosravi  
>>  wrote:
>>> Dear all,
>>>
>>> I've spend the last 2 hours experimenting with a PVS based UDO that
>>> takes the fft bins and randomly distributes each bin to one of six
>>> speakers upon each fft window pass. After this I pass the pvs signal
>>> through pvsoomth to make the scattering of bins more diffused. The
>>> result?? Pure joy! Importantly the individual speakers are not  
>>> really
>>> noticed even if you sit right next to them, the material is truly
>>> diffused in the listening space. The speakers just sort of become
>>> invisible! I would like to make different versions of this with more
>>> controls and so on.
>>>
>>> Has anyone experimented with similar things?? I'd be very interested
>>> to hear about your experiences.
>>>
>>> Best,
>>>
>>> Peiman
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/? 
>> group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yes if I use pvsmooth it does a little. But I only use pvsmooth on an
already sustained pitched sound. With more transient/noisy sounds I
just turn the smoothing factors to 1.

Peiman

On 16 January 2011 19:51, Victor Lazzarini  wrote:
> does the processing alter the timbral characteristics of the sound. I am
> wondering because
> you mentioned using pvsmooth.
>
> Victor
> On 16 Jan 2011, at 19:44, peiman khosravi wrote:
>
>> Yes exactly. How did you modulate each partial? Where you using
>> partial tracking or straight FFT?
>>
>> Interestingly certain sound extremely elevated when processed in this
>> way (I mean literary overhead).
>>
>> Thanks
>>
>> Peiman
>>
>> On 16 January 2011 19:32, Joel Ross  wrote:
>>>
>>> Yes, but I never got to hear it properly!
>>>
>>> I performed an additive synthesis of some sounds using a udo which read
>>> prom a table produced by pvsftw. Did you do something like this?
>>>
>>> I also found I could further process each partial independently to
>>> produce
>>> some really interesting effects for example by modulating the frequency
>>> of
>>> the partials at audio rate.
>>>
>>> -Joel
>>>
>>> On 16 January 2011 20:21, peiman khosravi 
>>> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> I've spend the last 2 hours experimenting with a PVS based UDO that
>>>> takes the fft bins and randomly distributes each bin to one of six
>>>> speakers upon each fft window pass. After this I pass the pvs signal
>>>> through pvsoomth to make the scattering of bins more diffused. The
>>>> result?? Pure joy! Importantly the individual speakers are not really
>>>> noticed even if you sit right next to them, the material is truly
>>>> diffused in the listening space. The speakers just sort of become
>>>> invisible! I would like to make different versions of this with more
>>>> controls and so on.
>>>>
>>>> Has anyone experimented with similar things?? I'd be very interested
>>>> to hear about your experiences.
>>>>
>>>> Best,
>>>>
>>>> Peiman
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Also a more interesting result is achieved if I load a stereo input
file. The bins of the left channel are then distributed among three
speakers on the left and the bins of the right channel among the three
speakers on the right. The result is that the sense of spatial
animation in the original stereo image is sort of preserved. This
gives a kind of overhead image with higher frequency granular
textures. weird.

Best,

Peiman

On 16 January 2011 19:57, peiman khosravi  wrote:
> Yes if I use pvsmooth it does a little. But I only use pvsmooth on an
> already sustained pitched sound. With more transient/noisy sounds I
> just turn the smoothing factors to 1.
>
> Peiman
>
> On 16 January 2011 19:51, Victor Lazzarini  wrote:
>> does the processing alter the timbral characteristics of the sound. I am
>> wondering because
>> you mentioned using pvsmooth.
>>
>> Victor
>> On 16 Jan 2011, at 19:44, peiman khosravi wrote:
>>
>>> Yes exactly. How did you modulate each partial? Where you using
>>> partial tracking or straight FFT?
>>>
>>> Interestingly certain sound extremely elevated when processed in this
>>> way (I mean literary overhead).
>>>
>>> Thanks
>>>
>>> Peiman
>>>
>>> On 16 January 2011 19:32, Joel Ross  wrote:
>>>>
>>>> Yes, but I never got to hear it properly!
>>>>
>>>> I performed an additive synthesis of some sounds using a udo which read
>>>> prom a table produced by pvsftw. Did you do something like this?
>>>>
>>>> I also found I could further process each partial independently to
>>>> produce
>>>> some really interesting effects for example by modulating the frequency
>>>> of
>>>> the partials at audio rate.
>>>>
>>>> -Joel
>>>>
>>>> On 16 January 2011 20:21, peiman khosravi 
>>>> wrote:
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I've spend the last 2 hours experimenting with a PVS based UDO that
>>>>> takes the fft bins and randomly distributes each bin to one of six
>>>>> speakers upon each fft window pass. After this I pass the pvs signal
>>>>> through pvsoomth to make the scattering of bins more diffused. The
>>>>> result?? Pure joy! Importantly the individual speakers are not really
>>>>> noticed even if you sit right next to them, the material is truly
>>>>> diffused in the listening space. The speakers just sort of become
>>>>> invisible! I would like to make different versions of this with more
>>>>> controls and so on.
>>>>>
>>>>> Has anyone experimented with similar things?? I'd be very interested
>>>>> to hear about your experiences.
>>>>>
>>>>> Best,
>>>>>
>>>>> Peiman
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>> csound"
>>>>>
>>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I found that I could use adsynt to do the additive synthesis instead
of bringing the data
back into fsig format. This had some problems, and also didn't have
any real benefit over
using pvsadsyn. I recreated the behaviour of adsynt using a recursive
udo, so I had one
oscillator for each partial, and could process it further in many
different ways.

The reason that I'd wanted to do this was because I wanted to try to
produce a smooth
transition between a sound and noise. I found that modulating a sine
wave against
downsampled noise produces a sort of noisy formant around its centre
freq., and stacking
many of these across the frequency range produces fairly convincing
white noise. It was
possible then to alter the bandwidth of each partial of my sound to
produce more and
less noisy versions.

I'd really love to hear this done distributed as you describe on a
multi-speaker setup,
it was church bells I'd wanted to do this to, coalescing from and
decaying back into noise,
being surrounded by all of the shifting partials like being inside the bells.

There was one caveat however, and I wonder if Victor might be able to
shed some light on this.
When doing additive synthesis in this way from the table produced by
pvsftw, if ksamps is more
than 1, then a nasty ring is introduced at a very high frequency. This
means that the results
take forever to render as I have to put the krate right up. I realise
that pvsftw is writing the table
at less regularly than krate, and I did have some problems with
clicking, but interpolation of the
amplitude values smoothed this out. I was still left with the ringing
sound however. Why might this be?

(I'm afraid I don't have the .csd but maybe the problem is really obvious.)

Thanks,
 Joel

On 16 January 2011 20:44, peiman khosravi  wrote:
> Yes exactly. How did you modulate each partial? Where you using
> partial tracking or straight FFT?
>
> Interestingly certain sound extremely elevated when processed in this
> way (I mean literary overhead).
>
> Thanks
>
> Peiman
>
> On 16 January 2011 19:32, Joel Ross  wrote:
>> Yes, but I never got to hear it properly!
>>
>> I performed an additive synthesis of some sounds using a udo which read
>> prom a table produced by pvsftw. Did you do something like this?
>>
>> I also found I could further process each partial independently to produce
>> some really interesting effects for example by modulating the frequency of
>> the partials at audio rate.
>>
>> -Joel
>>
>> On 16 January 2011 20:21, peiman khosravi  wrote:
>>> Dear all,
>>>
>>> I've spend the last 2 hours experimenting with a PVS based UDO that
>>> takes the fft bins and randomly distributes each bin to one of six
>>> speakers upon each fft window pass. After this I pass the pvs signal
>>> through pvsoomth to make the scattering of bins more diffused. The
>>> result?? Pure joy! Importantly the individual speakers are not really
>>> noticed even if you sit right next to them, the material is truly
>>> diffused in the listening space. The speakers just sort of become
>>> invisible! I would like to make different versions of this with more
>>> controls and so on.
>>>
>>> Has anyone experimented with similar things?? I'd be very interested
>>> to hear about your experiences.
>>>
>>> Best,
>>>
>>> Peiman
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks for the detail, it sound very interesting.

I think update rate of windows is dependent on the control rate. So
you are probably getting a modulation. I suspect if you smooth the
frequency changes the modulation should go away (they are probably
changing in steps at a periodic rate which is creating the hight
frequency pitch).

With a ksamps of 1 the pitch is probably above 20000 Hz which explains
why you don't hear it. Do a sonogram analysis and I bet you will see
it.
However, this is a wild guess I am sure Victor will clarify it.

Best,
Peiman


On 16 January 2011 20:58, Joel Ross  wrote:
> I found that I could use adsynt to do the additive synthesis instead
> of bringing the data
> back into fsig format. This had some problems, and also didn't have
> any real benefit over
> using pvsadsyn. I recreated the behaviour of adsynt using a recursive
> udo, so I had one
> oscillator for each partial, and could process it further in many
> different ways.
>
> The reason that I'd wanted to do this was because I wanted to try to
> produce a smooth
> transition between a sound and noise. I found that modulating a sine
> wave against
> downsampled noise produces a sort of noisy formant around its centre
> freq., and stacking
> many of these across the frequency range produces fairly convincing
> white noise. It was
> possible then to alter the bandwidth of each partial of my sound to
> produce more and
> less noisy versions.
>
> I'd really love to hear this done distributed as you describe on a
> multi-speaker setup,
> it was church bells I'd wanted to do this to, coalescing from and
> decaying back into noise,
> being surrounded by all of the shifting partials like being inside the bells.
>
> There was one caveat however, and I wonder if Victor might be able to
> shed some light on this.
> When doing additive synthesis in this way from the table produced by
> pvsftw, if ksamps is more
> than 1, then a nasty ring is introduced at a very high frequency. This
> means that the results
> take forever to render as I have to put the krate right up. I realise
> that pvsftw is writing the table
> at less regularly than krate, and I did have some problems with
> clicking, but interpolation of the
> amplitude values smoothed this out. I was still left with the ringing
> sound however. Why might this be?
>
> (I'm afraid I don't have the .csd but maybe the problem is really obvious.)
>
> Thanks,
>  Joel
>
> On 16 January 2011 20:44, peiman khosravi  wrote:
>> Yes exactly. How did you modulate each partial? Where you using
>> partial tracking or straight FFT?
>>
>> Interestingly certain sound extremely elevated when processed in this
>> way (I mean literary overhead).
>>
>> Thanks
>>
>> Peiman
>>
>> On 16 January 2011 19:32, Joel Ross  wrote:
>>> Yes, but I never got to hear it properly!
>>>
>>> I performed an additive synthesis of some sounds using a udo which read
>>> prom a table produced by pvsftw. Did you do something like this?
>>>
>>> I also found I could further process each partial independently to produce
>>> some really interesting effects for example by modulating the frequency of
>>> the partials at audio rate.
>>>
>>> -Joel
>>>
>>> On 16 January 2011 20:21, peiman khosravi  wrote:
>>>> Dear all,
>>>>
>>>> I've spend the last 2 hours experimenting with a PVS based UDO that
>>>> takes the fft bins and randomly distributes each bin to one of six
>>>> speakers upon each fft window pass. After this I pass the pvs signal
>>>> through pvsoomth to make the scattering of bins more diffused. The
>>>> result?? Pure joy! Importantly the individual speakers are not really
>>>> noticed even if you sit right next to them, the material is truly
>>>> diffused in the listening space. The speakers just sort of become
>>>> invisible! I would like to make different versions of this with more
>>>> controls and so on.
>>>>
>>>> Has anyone experimented with similar things?? I'd be very interested
>>>> to hear about your experiences.
>>>>
>>>> Best,
>>>>
>>>> Peiman
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

fsigs change at a different rate than kr - from the manual page for pvsftr:
"Except when the frame overlap equals ksmps (which will generally not be the case), the frame data is not updated each control period.The data in ifna, ifnf should only be processed when kflag is set to 1"

It should be possible to calculate when your data is ready to use (in sync with kr) even when not using pvsftr.

Unless the frequencies generated were between 20000 and nyquist (which will usually be a very narrow range of frequencies) they will fold over and become harmonically unrelated frequencies, so I don't think that is the issue. I think it is using the data before it is synced up between fsig and kr that causes the ringing. 

Also, the pvs algorithm counts on phase cancellations as part of the reproduction of your signal, and the phase cancellations are prevented when you split off frequencies arbitrarily. Something like ats is meant for meaningful signal extraction (though pvs fsigs are a fascinating way to distort and play with an input sound, they pretty much are guaranteed to distort when you start doing anything interesting beyond a simple frequency shift or time stretch).

peiman khosravi wrote:
> Thanks for the detail, it sound very interesting.
> 
> I think update rate of windows is dependent on the control rate. So
> you are probably getting a modulation. I suspect if you smooth the
> frequency changes the modulation should go away (they are probably
> changing in steps at a periodic rate which is creating the hight
> frequency pitch).
> 
> With a ksamps of 1 the pitch is probably above 20000 Hz which explains
> why you don't hear it. Do a sonogram analysis and I bet you will see
> it.
> However, this is a wild guess I am sure Victor will clarify it.
> 
> Best,
> Peiman
> 
> 
> On 16 January 2011 20:58, Joel Ross  wrote:
>> I found that I could use adsynt to do the additive synthesis instead
>> of bringing the data
>> back into fsig format. This had some problems, and also didn't have
>> any real benefit over
>> using pvsadsyn. I recreated the behaviour of adsynt using a recursive
>> udo, so I had one
>> oscillator for each partial, and could process it further in many
>> different ways.
>>
>> The reason that I'd wanted to do this was because I wanted to try to
>> produce a smooth
>> transition between a sound and noise. I found that modulating a sine
>> wave against
>> downsampled noise produces a sort of noisy formant around its centre
>> freq., and stacking
>> many of these across the frequency range produces fairly convincing
>> white noise. It was
>> possible then to alter the bandwidth of each partial of my sound to
>> produce more and
>> less noisy versions.
>>
>> I'd really love to hear this done distributed as you describe on a
>> multi-speaker setup,
>> it was church bells I'd wanted to do this to, coalescing from and
>> decaying back into noise,
>> being surrounded by all of the shifting partials like being inside the bells.
>>
>> There was one caveat however, and I wonder if Victor might be able to
>> shed some light on this.
>> When doing additive synthesis in this way from the table produced by
>> pvsftw, if ksamps is more
>> than 1, then a nasty ring is introduced at a very high frequency. This
>> means that the results
>> take forever to render as I have to put the krate right up. I realise
>> that pvsftw is writing the table
>> at less regularly than krate, and I did have some problems with
>> clicking, but interpolation of the
>> amplitude values smoothed this out. I was still left with the ringing
>> sound however. Why might this be?
>>
>> (I'm afraid I don't have the .csd but maybe the problem is really obvious.)
>>
>> Thanks,
>>  Joel
>>
>> On 16 January 2011 20:44, peiman khosravi  wrote:
>>> Yes exactly. How did you modulate each partial? Where you using
>>> partial tracking or straight FFT?
>>>
>>> Interestingly certain sound extremely elevated when processed in this
>>> way (I mean literary overhead).
>>>
>>> Thanks
>>>
>>> Peiman
>>>
>>> On 16 January 2011 19:32, Joel Ross  wrote:
>>>> Yes, but I never got to hear it properly!
>>>>
>>>> I performed an additive synthesis of some sounds using a udo which read
>>>> prom a table produced by pvsftw. Did you do something like this?
>>>>
>>>> I also found I could further process each partial independently to produce
>>>> some really interesting effects for example by modulating the frequency of
>>>> the partials at audio rate.
>>>>
>>>> -Joel
>>>>
>>>> On 16 January 2011 20:21, peiman khosravi  wrote:
>>>>> Dear all,
>>>>>
>>>>> I've spend the last 2 hours experimenting with a PVS based UDO that
>>>>> takes the fft bins and randomly distributes each bin to one of six
>>>>> speakers upon each fft window pass. After this I pass the pvs signal
>>>>> through pvsoomth to make the scattering of bins more diffused. The
>>>>> result?? Pure joy! Importantly the individual speakers are not really
>>>>> noticed even if you sit right next to them, the material is truly
>>>>> diffused in the listening space. The speakers just sort of become
>>>>> invisible! I would like to make different versions of this with more
>>>>> controls and so on.
>>>>>
>>>>> Has anyone experimented with similar things?? I'd be very interested
>>>>> to hear about your experiences.
>>>>>
>>>>> Best,
>>>>>
>>>>> Peiman
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 16 January 2011 22:21, Justin Glenn Smith  wrote:
> fsigs change at a different rate than kr - from the manual page for pvsftr:
> "Except when the frame overlap equals ksmps (which will generally not be the case), the frame data is not updated each control period.The data in ifna, ifnf should only be processed when kflag is set to 1"
>

Yes but it does not say that the update rate is independent. I think
it is updated every N control periods and I think that N is varied
depending on the context (I don't know what the context is).

> It should be possible to calculate when your data is ready to use (in sync with kr) even when not using pvsftr.
>
> Unless the frequencies generated were between 20000 and nyquist (which will usually be a very narrow range of frequencies) they will fold over and become harmonically unrelated frequencies, so I don't think that is the issue. I think it is using the data before it is synced up between fsig and kr that causes the ringing.
>

Well yes I was assuming that the frequencies were generated around the
nyquist limit.

I guess we should see the csd if possible?

> Also, the pvs algorithm counts on phase cancellations as part of the reproduction of your signal, and the phase cancellations are prevented when you split off frequencies arbitrarily. Something like ats is meant for meaningful signal extraction (though pvs fsigs are a fascinating way to distort and play with an input sound, they pretty much are guaranteed to distort when you start doing anything interesting beyond a simple frequency shift or time stretch).
>
There should not be (I think!) any obvious distortions (save the
windowing artifacts) if you are simply splitting the bins into
different tables - i.e. no modifications to the frequency data.
Actually frequency shift produces more phase distortion in my
experience. So I think there is a low of complex/interesting stuff
that can be done without even touching the frequency data. ATS is
great but unfortunately the partial/noise model is too simplistic for
real complex (non instrumental) sound sources.

Best,

Peiman

> peiman khosravi wrote:
>> Thanks for the detail, it sound very interesting.
>>
>> I think update rate of windows is dependent on the control rate. So
>> you are probably getting a modulation. I suspect if you smooth the
>> frequency changes the modulation should go away (they are probably
>> changing in steps at a periodic rate which is creating the hight
>> frequency pitch).
>>
>> With a ksamps of 1 the pitch is probably above 20000 Hz which explains
>> why you don't hear it. Do a sonogram analysis and I bet you will see
>> it.
>> However, this is a wild guess I am sure Victor will clarify it.
>>
>> Best,
>> Peiman
>>
>>
>> On 16 January 2011 20:58, Joel Ross  wrote:
>>> I found that I could use adsynt to do the additive synthesis instead
>>> of bringing the data
>>> back into fsig format. This had some problems, and also didn't have
>>> any real benefit over
>>> using pvsadsyn. I recreated the behaviour of adsynt using a recursive
>>> udo, so I had one
>>> oscillator for each partial, and could process it further in many
>>> different ways.
>>>
>>> The reason that I'd wanted to do this was because I wanted to try to
>>> produce a smooth
>>> transition between a sound and noise. I found that modulating a sine
>>> wave against
>>> downsampled noise produces a sort of noisy formant around its centre
>>> freq., and stacking
>>> many of these across the frequency range produces fairly convincing
>>> white noise. It was
>>> possible then to alter the bandwidth of each partial of my sound to
>>> produce more and
>>> less noisy versions.
>>>
>>> I'd really love to hear this done distributed as you describe on a
>>> multi-speaker setup,
>>> it was church bells I'd wanted to do this to, coalescing from and
>>> decaying back into noise,
>>> being surrounded by all of the shifting partials like being inside the bells.
>>>
>>> There was one caveat however, and I wonder if Victor might be able to
>>> shed some light on this.
>>> When doing additive synthesis in this way from the table produced by
>>> pvsftw, if ksamps is more
>>> than 1, then a nasty ring is introduced at a very high frequency. This
>>> means that the results
>>> take forever to render as I have to put the krate right up. I realise
>>> that pvsftw is writing the table
>>> at less regularly than krate, and I did have some problems with
>>> clicking, but interpolation of the
>>> amplitude values smoothed this out. I was still left with the ringing
>>> sound however. Why might this be?
>>>
>>> (I'm afraid I don't have the .csd but maybe the problem is really obvious.)
>>>
>>> Thanks,
>>>  Joel
>>>
>>> On 16 January 2011 20:44, peiman khosravi  wrote:
>>>> Yes exactly. How did you modulate each partial? Where you using
>>>> partial tracking or straight FFT?
>>>>
>>>> Interestingly certain sound extremely elevated when processed in this
>>>> way (I mean literary overhead).
>>>>
>>>> Thanks
>>>>
>>>> Peiman
>>>>
>>>> On 16 January 2011 19:32, Joel Ross  wrote:
>>>>> Yes, but I never got to hear it properly!
>>>>>
>>>>> I performed an additive synthesis of some sounds using a udo which read
>>>>> prom a table produced by pvsftw. Did you do something like this?
>>>>>
>>>>> I also found I could further process each partial independently to produce
>>>>> some really interesting effects for example by modulating the frequency of
>>>>> the partials at audio rate.
>>>>>
>>>>> -Joel
>>>>>
>>>>> On 16 January 2011 20:21, peiman khosravi  wrote:
>>>>>> Dear all,
>>>>>>
>>>>>> I've spend the last 2 hours experimenting with a PVS based UDO that
>>>>>> takes the fft bins and randomly distributes each bin to one of six
>>>>>> speakers upon each fft window pass. After this I pass the pvs signal
>>>>>> through pvsoomth to make the scattering of bins more diffused. The
>>>>>> result?? Pure joy! Importantly the individual speakers are not really
>>>>>> noticed even if you sit right next to them, the material is truly
>>>>>> diffused in the listening space. The speakers just sort of become
>>>>>> invisible! I would like to make different versions of this with more
>>>>>> controls and so on.
>>>>>>
>>>>>> Has anyone experimented with similar things?? I'd be very interested
>>>>>> to hear about your experiences.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Peiman
>>>>>>
>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

No, they are working as before.
On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:

> 2) does anyone use the LP opcodes? They seem broken anyway...maybe  
> they should be dropped from the code base?



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

pvspitch?

On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:

> 3) Is there a way to get human readable data from a PVS analysis,  
> summary data that is, for instance--the perceived pitch of this  
> teapot clang is 325.756 hz for most of the signal...or is that too  
> subjective a reality?



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

My thought on this is that it is possible, but it might be expensive.  
You will need to sort all bins by amp, until the number of requested  
bins is
reached.

On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:

> 4) is there a way to tell csound to pick, say, the 13 loudest bins  
> only...it seems like you have to tell it which bins you want, but  
> what if you don't know in advance, or want to make the decision  
> based on loudness, info it should already have, in effect?



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

peiman khosravi wrote:
...
> There should not be (I think!) any obvious distortions (save the
> windowing artifacts) if you are simply splitting the bins into
> different tables - i.e. no modifications to the frequency data.
> Actually frequency shift produces more phase distortion in my
> experience. So I think there is a low of complex/interesting stuff
> that can be done without even touching the frequency data. ATS is
> great but unfortunately the partial/noise model is too simplistic for
> real complex (non instrumental) sound sources.

With just a simple shift, applied evenly to all bins, there will be no phase distortion at all.

pvs can encode more frequency content than the number of bins present, because of phase relationships between the frequencies being part of the encoding of the sound.

Also, notice that pvs can recreate a pitched sound with a fundamental frequency, and harmonics, that do not match any of the bin frequencies (the bin frequencies are fixed in number and frequency and evenly spaced, this is how fourier based transforms work). Recreating frequencies that are not in any of the bins is possible due to the amplitude phase relationships between the bins interacting to create the sound - the resynthesis perfectly mirrors and therefore cancels the distortions of the analysis so you get your original sound back (within the limits of the quality of the analysis and resynthesis, shortcuts are of course made for efficiency reasons).

When you take some bins out, or apply different changes to different bins, artifacts will be produced (more artifacts for more complex sounds, fewer with simpler sounds).

Manipulating frequency data in pvs, except the singular cases of time stretching or pitch shifting, is a form of distortion. Just like any other distortion it can be musically interesting, but there is no mystery in the fact that it will produce sounds that have very little relationship to the input material. The book "microsound" by Curtis Roads has a really clear explanation of this, if my own clumsy explanation is failing.


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yes I have a csd that does this. Use pvsftw to write the bin values to
a table. Then inside a UDO loop through the bins and set the amp
values bellow a certain threshold to zero (or near zero if you want to
avoid de-normalization issues).

But as Victor says it's expensive. This is one area where
multithreading would really be welcome.

P

On 16 January 2011 23:53, Victor Lazzarini  wrote:
> My thought on this is that it is possible, but it might be expensive. You
> will need to sort all bins by amp, until the number of requested bins is
> reached.
>
> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>
>> 4) is there a way to tell csound to pick, say, the 13 loudest bins
>> only...it seems like you have to tell it which bins you want, but what if
>> you don't know in advance, or want to make the decision based on loudness,
>> info it should already have, in effect?
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.

A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.

Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).

Aaron Krister Johnson wrote:
> So, there are no existing opcodes or tools for this, I take it...one would
> have to write a script in the language of one's choosing based on output
> from pvlook?
> 
> AKJ
> 
> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
> wrote:
> 
>> My thought on this is that it is possible, but it might be expensive. You
>> will need to sort all bins by amp, until the number of requested bins is
>> reached.
>>
>>
>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>
>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>> only...it seems like you have to tell it which bins you want, but what if
>>> you don't know in advance, or want to make the decision based on loudness,
>>> info it should already have, in effect?
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
> 
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

No makes sense.

So if you zero the amplitude of certain bins (without touching the
frequency) then you get distortions in the resynthesised signal?

P

On 17 January 2011 00:11, Justin Glenn Smith  wrote:
> peiman khosravi wrote:
> ...
>> There should not be (I think!) any obvious distortions (save the
>> windowing artifacts) if you are simply splitting the bins into
>> different tables - i.e. no modifications to the frequency data.
>> Actually frequency shift produces more phase distortion in my
>> experience. So I think there is a low of complex/interesting stuff
>> that can be done without even touching the frequency data. ATS is
>> great but unfortunately the partial/noise model is too simplistic for
>> real complex (non instrumental) sound sources.
>
> With just a simple shift, applied evenly to all bins, there will be no phase distortion at all.
>
> pvs can encode more frequency content than the number of bins present, because of phase relationships between the frequencies being part of the encoding of the sound.
>
> Also, notice that pvs can recreate a pitched sound with a fundamental frequency, and harmonics, that do not match any of the bin frequencies (the bin frequencies are fixed in number and frequency and evenly spaced, this is how fourier based transforms work). Recreating frequencies that are not in any of the bins is possible due to the amplitude phase relationships between the bins interacting to create the sound - the resynthesis perfectly mirrors and therefore cancels the distortions of the analysis so you get your original sound back (within the limits of the quality of the analysis and resynthesis, shortcuts are of course made for efficiency reasons).
>
> When you take some bins out, or apply different changes to different bins, artifacts will be produced (more artifacts for more complex sounds, fewer with simpler sounds).
>
> Manipulating frequency data in pvs, except the singular cases of time stretching or pitch shifting, is a form of distortion. Just like any other distortion it can be musically interesting, but there is no mystery in the fact that it will produce sounds that have very little relationship to the input material. The book "microsound" by Curtis Roads has a really clear explanation of this, if my own clumsy explanation is failing.
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

clarify: No, makes sense. How important is a comma!

On 17 January 2011 00:25, peiman khosravi  wrote:
> No makes sense.
>
> So if you zero the amplitude of certain bins (without touching the
> frequency) then you get distortions in the resynthesised signal?
>
> P
>
> On 17 January 2011 00:11, Justin Glenn Smith  wrote:
>> peiman khosravi wrote:
>> ...
>>> There should not be (I think!) any obvious distortions (save the
>>> windowing artifacts) if you are simply splitting the bins into
>>> different tables - i.e. no modifications to the frequency data.
>>> Actually frequency shift produces more phase distortion in my
>>> experience. So I think there is a low of complex/interesting stuff
>>> that can be done without even touching the frequency data. ATS is
>>> great but unfortunately the partial/noise model is too simplistic for
>>> real complex (non instrumental) sound sources.
>>
>> With just a simple shift, applied evenly to all bins, there will be no phase distortion at all.
>>
>> pvs can encode more frequency content than the number of bins present, because of phase relationships between the frequencies being part of the encoding of the sound.
>>
>> Also, notice that pvs can recreate a pitched sound with a fundamental frequency, and harmonics, that do not match any of the bin frequencies (the bin frequencies are fixed in number and frequency and evenly spaced, this is how fourier based transforms work). Recreating frequencies that are not in any of the bins is possible due to the amplitude phase relationships between the bins interacting to create the sound - the resynthesis perfectly mirrors and therefore cancels the distortions of the analysis so you get your original sound back (within the limits of the quality of the analysis and resynthesis, shortcuts are of course made for efficiency reasons).
>>
>> When you take some bins out, or apply different changes to different bins, artifacts will be produced (more artifacts for more complex sounds, fewer with simpler sounds).
>>
>> Manipulating frequency data in pvs, except the singular cases of time stretching or pitch shifting, is a form of distortion. Just like any other distortion it can be musically interesting, but there is no mystery in the fact that it will produce sounds that have very little relationship to the input material. The book "microsound" by Curtis Roads has a really clear explanation of this, if my own clumsy explanation is failing.
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

> A better option would be to make an opcode,

Doesn't pvstencil already do that if you set the gain to zero?

P


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:

fft based analysis / resynthesis does not get you "the frequencies" of the original sound

it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well

manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement

Justin Glenn Smith wrote:
> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
> 
> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
> 
> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
> 
> Aaron Krister Johnson wrote:
>> So, there are no existing opcodes or tools for this, I take it...one would
>> have to write a script in the language of one's choosing based on output
>> from pvlook?
>>
>> AKJ
>>
>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>> wrote:
>>
>>> My thought on this is that it is possible, but it might be expensive. You
>>> will need to sort all bins by amp, until the number of requested bins is
>>> reached.
>>>
>>>
>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>
>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>> only...it seems like you have to tell it which bins you want, but what if
>>>> you don't know in advance, or want to make the decision based on loudness,
>>>> info it should already have, in effect?
>>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
> 
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yes, see my attempt at a more articulate explanation elsewhere in this thread. The number of ways you can split a sound into frequencies is provably infinite (actually you don't even need to use pure frequencies, see wavelet analysis / resynthesis for example - literally any waveform can be used as the basis for decomposing then recomposing a sound, the math is easier with sine waves though).

Changing solitary bins runs the risk of revealing more to the listener about your splitting method than the input sound (though with some skill and some subtlety you can definitely get some great results, it just isn't as foolproof as people seem to intuit it should be).

peiman khosravi wrote:
> clarify: No, makes sense. How important is a comma!
> 
> On 17 January 2011 00:25, peiman khosravi  wrote:
>> No makes sense.
>>
>> So if you zero the amplitude of certain bins (without touching the
>> frequency) then you get distortions in the resynthesised signal?
>>
>> P
>>
>> On 17 January 2011 00:11, Justin Glenn Smith  wrote:
>>> peiman khosravi wrote:
>>> ...
>>>> There should not be (I think!) any obvious distortions (save the
>>>> windowing artifacts) if you are simply splitting the bins into
>>>> different tables - i.e. no modifications to the frequency data.
>>>> Actually frequency shift produces more phase distortion in my
>>>> experience. So I think there is a low of complex/interesting stuff
>>>> that can be done without even touching the frequency data. ATS is
>>>> great but unfortunately the partial/noise model is too simplistic for
>>>> real complex (non instrumental) sound sources.
>>> With just a simple shift, applied evenly to all bins, there will be no phase distortion at all.
>>>
>>> pvs can encode more frequency content than the number of bins present, because of phase relationships between the frequencies being part of the encoding of the sound.
>>>
>>> Also, notice that pvs can recreate a pitched sound with a fundamental frequency, and harmonics, that do not match any of the bin frequencies (the bin frequencies are fixed in number and frequency and evenly spaced, this is how fourier based transforms work). Recreating frequencies that are not in any of the bins is possible due to the amplitude phase relationships between the bins interacting to create the sound - the resynthesis perfectly mirrors and therefore cancels the distortions of the analysis so you get your original sound back (within the limits of the quality of the analysis and resynthesis, shortcuts are of course made for efficiency reasons).
>>>
>>> When you take some bins out, or apply different changes to different bins, artifacts will be produced (more artifacts for more complex sounds, fewer with simpler sounds).
>>>
>>> Manipulating frequency data in pvs, except the singular cases of time stretching or pitch shifting, is a form of distortion. Just like any other distortion it can be musically interesting, but there is no mystery in the fact that it will produce sounds that have very little relationship to the input material. The book "microsound" by Curtis Roads has a really clear explanation of this, if my own clumsy explanation is failing.
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yes I get your point. I know that changing the frequency data of the
FFT signal, which is not the same as the pure frequency data in your
input signal (i.e. the partials) is a bad idea. My question was, would
changing the amplitude values give you a distorted output?

Let me rephrase it.

1- Say I have two audio channels. I now split my FFT bins into two
groups, sending half the bins (amplitude and frequency pairs) to the
first and the other half to the second channel.
2- I also make a version in which all the bins go into the same channel
3- now mix the two channels in the first version into a mono signal.

The question is are you getting the same result in experiments #2 and 3?

Thanks

Peiman

On 17 January 2011 00:32, Justin Glenn Smith  wrote:
> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>
> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>
> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>
> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>
> Justin Glenn Smith wrote:
>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>
>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>
>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>
>> Aaron Krister Johnson wrote:
>>> So, there are no existing opcodes or tools for this, I take it...one would
>>> have to write a script in the language of one's choosing based on output
>>> from pvlook?
>>>
>>> AKJ
>>>
>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>> wrote:
>>>
>>>> My thought on this is that it is possible, but it might be expensive. You
>>>> will need to sort all bins by amp, until the number of requested bins is
>>>> reached.
>>>>
>>>>
>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>
>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>> info it should already have, in effect?
>>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).

2 and 3 get you the same signal

But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.

The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.

peiman khosravi wrote:
> Yes I get your point. I know that changing the frequency data of the
> FFT signal, which is not the same as the pure frequency data in your
> input signal (i.e. the partials) is a bad idea. My question was, would
> changing the amplitude values give you a distorted output?
> 
> Let me rephrase it.
> 
> 1- Say I have two audio channels. I now split my FFT bins into two
> groups, sending half the bins (amplitude and frequency pairs) to the
> first and the other half to the second channel.
> 2- I also make a version in which all the bins go into the same channel
> 3- now mix the two channels in the first version into a mono signal.
> 
> The question is are you getting the same result in experiments #2 and 3?
> 
> Thanks
> 
> Peiman
> 
> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>
>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>
>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>
>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>
>> Justin Glenn Smith wrote:
>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>
>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>
>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>
>>> Aaron Krister Johnson wrote:
>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>> have to write a script in the language of one's choosing based on output
>>>> from pvlook?
>>>>
>>>> AKJ
>>>>
>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>> wrote:
>>>>
>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>> reached.
>>>>>
>>>>>
>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>
>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>> info it should already have, in effect?
>>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>> csound"
>>>>>
>>>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yes I read your emails a couple of times after sending that!

I'm glad 2 and 3 give the same result! I am not sure if distortion is
the right word here. Alterations for sure, but then you expect such
alterations otherwise what's the point of processing.

What do you mean by distortion exactly? Naturally if we kill a couple
of bins we will not have the same sound as the original input signal.
What I was referring to is that sort of blurring effect (loosing the
transients) you get if you start messing with the frequency data of
the bins. The bins do actually posses a frequency data right? This
does not happen if you do not touch the frequency data (in my limited
experience).

Thanks

Peiman

On 17 January 2011 01:17, Justin Glenn Smith  wrote:
> But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).
>
> 2 and 3 get you the same signal
>
> But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.
>
> The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.
>
> peiman khosravi wrote:
>> Yes I get your point. I know that changing the frequency data of the
>> FFT signal, which is not the same as the pure frequency data in your
>> input signal (i.e. the partials) is a bad idea. My question was, would
>> changing the amplitude values give you a distorted output?
>>
>> Let me rephrase it.
>>
>> 1- Say I have two audio channels. I now split my FFT bins into two
>> groups, sending half the bins (amplitude and frequency pairs) to the
>> first and the other half to the second channel.
>> 2- I also make a version in which all the bins go into the same channel
>> 3- now mix the two channels in the first version into a mono signal.
>>
>> The question is are you getting the same result in experiments #2 and 3?
>>
>> Thanks
>>
>> Peiman
>>
>> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>>
>>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>>
>>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>>
>>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>>
>>> Justin Glenn Smith wrote:
>>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>>
>>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>>
>>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>>
>>>> Aaron Krister Johnson wrote:
>>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>>> have to write a script in the language of one's choosing based on output
>>>>> from pvlook?
>>>>>
>>>>> AKJ
>>>>>
>>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>>> wrote:
>>>>>
>>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>>> reached.
>>>>>>
>>>>>>
>>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>>
>>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>>> info it should already have, in effect?
>>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>>> csound"
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

If you have an analysis size of 512, and sr of 44100, you have the following frequencies stored:
0
43.06640625
all of the harmonics of 43.06640625 hz that are below nyquist 

Nothing else, whatsoever.

Frequencies that are not in that list are recreated during synthesis but not directly stored. They are generated by cancellations based on phase relationships between frequencies in that list. When you drop a large enough number of bins, 43.06640625 hz and its harmonics will dominate the result more and more.

With transposition during resynthesis you are changing the phase cancellations evenly with the original pitches. Therefore your original spectrum comes through, in shifted form - the spectrum is shifted, but no spectral information is lost, you don't get arbitrary spectral distortion.

I call the change that happens with dropping bins a distortion because it is doing something you likely don't want - not just filtering out part of the frequency content, but doing arbitrary frequency shifts, the nature of which are determined by the number of analysis bins and the sampling rate. I think that this can be mitigated by grabbing groups of adjacent frequencies around the biggest spectral peaks, rather than just grabbing the biggest peaks. Perhaps using an envelope, where the amplitude is decreased as one gets further from the peak in the spectrum would be helpful as well, but this is just a hypothesis, I haven't tried it.

peiman khosravi wrote:
> Yes I read your emails a couple of times after sending that!
> 
> I'm glad 2 and 3 give the same result! I am not sure if distortion is
> the right word here. Alterations for sure, but then you expect such
> alterations otherwise what's the point of processing.
> 
> What do you mean by distortion exactly? Naturally if we kill a couple
> of bins we will not have the same sound as the original input signal.
> What I was referring to is that sort of blurring effect (loosing the
> transients) you get if you start messing with the frequency data of
> the bins. The bins do actually posses a frequency data right? This
> does not happen if you do not touch the frequency data (in my limited
> experience).
> 
> Thanks
> 
> Peiman
> 
> On 17 January 2011 01:17, Justin Glenn Smith  wrote:
>> But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).
>>
>> 2 and 3 get you the same signal
>>
>> But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.
>>
>> The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.
>>
>> peiman khosravi wrote:
>>> Yes I get your point. I know that changing the frequency data of the
>>> FFT signal, which is not the same as the pure frequency data in your
>>> input signal (i.e. the partials) is a bad idea. My question was, would
>>> changing the amplitude values give you a distorted output?
>>>
>>> Let me rephrase it.
>>>
>>> 1- Say I have two audio channels. I now split my FFT bins into two
>>> groups, sending half the bins (amplitude and frequency pairs) to the
>>> first and the other half to the second channel.
>>> 2- I also make a version in which all the bins go into the same channel
>>> 3- now mix the two channels in the first version into a mono signal.
>>>
>>> The question is are you getting the same result in experiments #2 and 3?
>>>
>>> Thanks
>>>
>>> Peiman
>>>
>>> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>>>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>>>
>>>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>>>
>>>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>>>
>>>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>>>
>>>> Justin Glenn Smith wrote:
>>>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>>>
>>>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>>>
>>>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>>>
>>>>> Aaron Krister Johnson wrote:
>>>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>>>> have to write a script in the language of one's choosing based on output
>>>>>> from pvlook?
>>>>>>
>>>>>> AKJ
>>>>>>
>>>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>>>> wrote:
>>>>>>
>>>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>>>> reached.
>>>>>>>
>>>>>>>
>>>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>>>
>>>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>>>> info it should already have, in effect?
>>>>>>>>
>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>>>> csound"
>>>>>>>
>>>>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Oh, and a more direct reply to your question "the bins do actually posses a frequency data right?": they contain the data implicitly, it is calculated based on the number of analysis bins and the sampling rate - the bins are divided into equal numbers of hz starting with 0 and going up to nyquist. And the frequency data is a convention shared between analysis and resynthesis - the frequencies represented by the bins are determined solely by the number of bins and the sampling rate, and have nothing to do with the input sound.

If you were to encode a pure sine wave doing a slow upward glissando into fft data, the bins would show clusters of active frequencies that would move higher over time and would always be centered on the actual input pitch. The number of bins with significant content would change - spreading wider to encompass more bins as the frequency is between bins, narrowing as the frequency approaches the exact frequency of a bin. If the frequency and phase line up perfectly you may actually get a lucky moment where only one bin has significant data.

If you were to decide that since it is only a single sine wave you can recreate it with a single bin, just picking the loudest bin at any moment, you would get a sound that jumps from one harmonic of the frequency step of the analysis to another, with no smooth sliding going on at all. And the amplitude would be very erratic, jumping higher as you approach a harmonic of your analysis' frequency step, and shrinking much lower when between them.

Justin Glenn Smith wrote:
> If you have an analysis size of 512, and sr of 44100, you have the following frequencies stored:
> 0
> 43.06640625
> all of the harmonics of 43.06640625 hz that are below nyquist 
> 
> Nothing else, whatsoever.
> 
> Frequencies that are not in that list are recreated during synthesis but not directly stored. They are generated by cancellations based on phase relationships between frequencies in that list. When you drop a large enough number of bins, 43.06640625 hz and its harmonics will dominate the result more and more.
> 
> With transposition during resynthesis you are changing the phase cancellations evenly with the original pitches. Therefore your original spectrum comes through, in shifted form - the spectrum is shifted, but no spectral information is lost, you don't get arbitrary spectral distortion.
> 
> I call the change that happens with dropping bins a distortion because it is doing something you likely don't want - not just filtering out part of the frequency content, but doing arbitrary frequency shifts, the nature of which are determined by the number of analysis bins and the sampling rate. I think that this can be mitigated by grabbing groups of adjacent frequencies around the biggest spectral peaks, rather than just grabbing the biggest peaks. Perhaps using an envelope, where the amplitude is decreased as one gets further from the peak in the spectrum would be helpful as well, but this is just a hypothesis, I haven't tried it.
> 
> peiman khosravi wrote:
>> Yes I read your emails a couple of times after sending that!
>>
>> I'm glad 2 and 3 give the same result! I am not sure if distortion is
>> the right word here. Alterations for sure, but then you expect such
>> alterations otherwise what's the point of processing.
>>
>> What do you mean by distortion exactly? Naturally if we kill a couple
>> of bins we will not have the same sound as the original input signal.
>> What I was referring to is that sort of blurring effect (loosing the
>> transients) you get if you start messing with the frequency data of
>> the bins. The bins do actually posses a frequency data right? This
>> does not happen if you do not touch the frequency data (in my limited
>> experience).
>>
>> Thanks
>>
>> Peiman
>>
>> On 17 January 2011 01:17, Justin Glenn Smith  wrote:
>>> But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).
>>>
>>> 2 and 3 get you the same signal
>>>
>>> But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.
>>>
>>> The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.
>>>
>>> peiman khosravi wrote:
>>>> Yes I get your point. I know that changing the frequency data of the
>>>> FFT signal, which is not the same as the pure frequency data in your
>>>> input signal (i.e. the partials) is a bad idea. My question was, would
>>>> changing the amplitude values give you a distorted output?
>>>>
>>>> Let me rephrase it.
>>>>
>>>> 1- Say I have two audio channels. I now split my FFT bins into two
>>>> groups, sending half the bins (amplitude and frequency pairs) to the
>>>> first and the other half to the second channel.
>>>> 2- I also make a version in which all the bins go into the same channel
>>>> 3- now mix the two channels in the first version into a mono signal.
>>>>
>>>> The question is are you getting the same result in experiments #2 and 3?
>>>>
>>>> Thanks
>>>>
>>>> Peiman
>>>>
>>>> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>>>>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>>>>
>>>>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>>>>
>>>>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>>>>
>>>>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>>>>
>>>>> Justin Glenn Smith wrote:
>>>>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>>>>
>>>>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>>>>
>>>>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>>>>
>>>>>> Aaron Krister Johnson wrote:
>>>>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>>>>> have to write a script in the language of one's choosing based on output
>>>>>>> from pvlook?
>>>>>>>
>>>>>>> AKJ
>>>>>>>
>>>>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>>>>> wrote:
>>>>>>>
>>>>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>>>>> reached.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>>>>
>>>>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>>>>> info it should already have, in effect?
>>>>>>>>>
>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>>>>> csound"
>>>>>>>>
>>>>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
> 
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks for the explanation. One last question please if you don't mind.

On 17 January 2011 01:55, Justin Glenn Smith  wrote:
> If you have an analysis size of 512, and sr of 44100, you have the following frequencies stored:
> 0
> 43.06640625
> all of the harmonics of 43.06640625 hz that are below nyquist
>

So you get the number 43.06640625 like this: (44100/2)/512. That is
the Nyquist divided evenly by the number of bins which gives you the
frequency bandwidth of each bin. I thought that for 512 bins you would
only get 256 usable bins as the other half goes above the Nyquist and
is therefore dropped. So in fact the formula should be like this:
(44100/2)/(512/2). Is that wrong?

Also do you mean to say that the frequencies stored are all
harmonically related (integer multiples of a fundamental) ?

Thanks

Peiman

> Nothing else, whatsoever.
>
> Frequencies that are not in that list are recreated during synthesis but not directly stored. They are generated by cancellations based on phase relationships between frequencies in that list. When you drop a large enough number of bins, 43.06640625 hz and its harmonics will dominate the result more and more.
>
> With transposition during resynthesis you are changing the phase cancellations evenly with the original pitches. Therefore your original spectrum comes through, in shifted form - the spectrum is shifted, but no spectral information is lost, you don't get arbitrary spectral distortion.
>
> I call the change that happens with dropping bins a distortion because it is doing something you likely don't want - not just filtering out part of the frequency content, but doing arbitrary frequency shifts, the nature of which are determined by the number of analysis bins and the sampling rate. I think that this can be mitigated by grabbing groups of adjacent frequencies around the biggest spectral peaks, rather than just grabbing the biggest peaks. Perhaps using an envelope, where the amplitude is decreased as one gets further from the peak in the spectrum would be helpful as well, but this is just a hypothesis, I haven't tried it.
>
> peiman khosravi wrote:
>> Yes I read your emails a couple of times after sending that!
>>
>> I'm glad 2 and 3 give the same result! I am not sure if distortion is
>> the right word here. Alterations for sure, but then you expect such
>> alterations otherwise what's the point of processing.
>>
>> What do you mean by distortion exactly? Naturally if we kill a couple
>> of bins we will not have the same sound as the original input signal.
>> What I was referring to is that sort of blurring effect (loosing the
>> transients) you get if you start messing with the frequency data of
>> the bins. The bins do actually posses a frequency data right? This
>> does not happen if you do not touch the frequency data (in my limited
>> experience).
>>
>> Thanks
>>
>> Peiman
>>
>> On 17 January 2011 01:17, Justin Glenn Smith  wrote:
>>> But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).
>>>
>>> 2 and 3 get you the same signal
>>>
>>> But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.
>>>
>>> The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.
>>>
>>> peiman khosravi wrote:
>>>> Yes I get your point. I know that changing the frequency data of the
>>>> FFT signal, which is not the same as the pure frequency data in your
>>>> input signal (i.e. the partials) is a bad idea. My question was, would
>>>> changing the amplitude values give you a distorted output?
>>>>
>>>> Let me rephrase it.
>>>>
>>>> 1- Say I have two audio channels. I now split my FFT bins into two
>>>> groups, sending half the bins (amplitude and frequency pairs) to the
>>>> first and the other half to the second channel.
>>>> 2- I also make a version in which all the bins go into the same channel
>>>> 3- now mix the two channels in the first version into a mono signal.
>>>>
>>>> The question is are you getting the same result in experiments #2 and 3?
>>>>
>>>> Thanks
>>>>
>>>> Peiman
>>>>
>>>> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>>>>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>>>>
>>>>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>>>>
>>>>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>>>>
>>>>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>>>>
>>>>> Justin Glenn Smith wrote:
>>>>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>>>>
>>>>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>>>>
>>>>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>>>>
>>>>>> Aaron Krister Johnson wrote:
>>>>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>>>>> have to write a script in the language of one's choosing based on output
>>>>>>> from pvlook?
>>>>>>>
>>>>>>> AKJ
>>>>>>>
>>>>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>>>>> wrote:
>>>>>>>
>>>>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>>>>> reached.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>>>>
>>>>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>>>>> info it should already have, in effect?
>>>>>>>>>
>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>>>>> csound"
>>>>>>>>
>>>>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yes I have experienced this many times.

Best,

Peiman

On 17 January 2011 02:17, Justin Glenn Smith  wrote:
> Oh, and a more direct reply to your question "the bins do actually posses a frequency data right?": they contain the data implicitly, it is calculated based on the number of analysis bins and the sampling rate - the bins are divided into equal numbers of hz starting with 0 and going up to nyquist. And the frequency data is a convention shared between analysis and resynthesis - the frequencies represented by the bins are determined solely by the number of bins and the sampling rate, and have nothing to do with the input sound.
>
> If you were to encode a pure sine wave doing a slow upward glissando into fft data, the bins would show clusters of active frequencies that would move higher over time and would always be centered on the actual input pitch. The number of bins with significant content would change - spreading wider to encompass more bins as the frequency is between bins, narrowing as the frequency approaches the exact frequency of a bin. If the frequency and phase line up perfectly you may actually get a lucky moment where only one bin has significant data.
>
> If you were to decide that since it is only a single sine wave you can recreate it with a single bin, just picking the loudest bin at any moment, you would get a sound that jumps from one harmonic of the frequency step of the analysis to another, with no smooth sliding going on at all. And the amplitude would be very erratic, jumping higher as you approach a harmonic of your analysis' frequency step, and shrinking much lower when between them.
>
> Justin Glenn Smith wrote:
>> If you have an analysis size of 512, and sr of 44100, you have the following frequencies stored:
>> 0
>> 43.06640625
>> all of the harmonics of 43.06640625 hz that are below nyquist
>>
>> Nothing else, whatsoever.
>>
>> Frequencies that are not in that list are recreated during synthesis but not directly stored. They are generated by cancellations based on phase relationships between frequencies in that list. When you drop a large enough number of bins, 43.06640625 hz and its harmonics will dominate the result more and more.
>>
>> With transposition during resynthesis you are changing the phase cancellations evenly with the original pitches. Therefore your original spectrum comes through, in shifted form - the spectrum is shifted, but no spectral information is lost, you don't get arbitrary spectral distortion.
>>
>> I call the change that happens with dropping bins a distortion because it is doing something you likely don't want - not just filtering out part of the frequency content, but doing arbitrary frequency shifts, the nature of which are determined by the number of analysis bins and the sampling rate. I think that this can be mitigated by grabbing groups of adjacent frequencies around the biggest spectral peaks, rather than just grabbing the biggest peaks. Perhaps using an envelope, where the amplitude is decreased as one gets further from the peak in the spectrum would be helpful as well, but this is just a hypothesis, I haven't tried it.
>>
>> peiman khosravi wrote:
>>> Yes I read your emails a couple of times after sending that!
>>>
>>> I'm glad 2 and 3 give the same result! I am not sure if distortion is
>>> the right word here. Alterations for sure, but then you expect such
>>> alterations otherwise what's the point of processing.
>>>
>>> What do you mean by distortion exactly? Naturally if we kill a couple
>>> of bins we will not have the same sound as the original input signal.
>>> What I was referring to is that sort of blurring effect (loosing the
>>> transients) you get if you start messing with the frequency data of
>>> the bins. The bins do actually posses a frequency data right? This
>>> does not happen if you do not touch the frequency data (in my limited
>>> experience).
>>>
>>> Thanks
>>>
>>> Peiman
>>>
>>> On 17 January 2011 01:17, Justin Glenn Smith  wrote:
>>>> But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).
>>>>
>>>> 2 and 3 get you the same signal
>>>>
>>>> But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.
>>>>
>>>> The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.
>>>>
>>>> peiman khosravi wrote:
>>>>> Yes I get your point. I know that changing the frequency data of the
>>>>> FFT signal, which is not the same as the pure frequency data in your
>>>>> input signal (i.e. the partials) is a bad idea. My question was, would
>>>>> changing the amplitude values give you a distorted output?
>>>>>
>>>>> Let me rephrase it.
>>>>>
>>>>> 1- Say I have two audio channels. I now split my FFT bins into two
>>>>> groups, sending half the bins (amplitude and frequency pairs) to the
>>>>> first and the other half to the second channel.
>>>>> 2- I also make a version in which all the bins go into the same channel
>>>>> 3- now mix the two channels in the first version into a mono signal.
>>>>>
>>>>> The question is are you getting the same result in experiments #2 and 3?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Peiman
>>>>>
>>>>> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>>>>>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>>>>>
>>>>>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>>>>>
>>>>>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>>>>>
>>>>>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>>>>>
>>>>>> Justin Glenn Smith wrote:
>>>>>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>>>>>
>>>>>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>>>>>
>>>>>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>>>>>
>>>>>>> Aaron Krister Johnson wrote:
>>>>>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>>>>>> have to write a script in the language of one's choosing based on output
>>>>>>>> from pvlook?
>>>>>>>>
>>>>>>>> AKJ
>>>>>>>>
>>>>>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>>>>>> reached.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>>>>>
>>>>>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>>>>>> info it should already have, in effect?
>>>>>>>>>>
>>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>>>>>> csound"
>>>>>>>>>
>>>>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 17 January 2011 02:17, Justin Glenn Smith  wrote:
> Oh, and a more direct reply to your question "the bins do actually posses a frequency data right?": they contain the data implicitly, it is calculated based on the number of analysis bins and the sampling rate - the bins are divided into equal numbers of hz starting with 0 and going up to nyquist. And the frequency data is a convention shared between analysis and resynthesis - the frequencies represented by the bins are determined solely by the number of bins and the sampling rate, and have nothing to do with the input sound.
>

To look at it differently one could say that the bins show the
relative energy of the sound within the frequency continuum. Each bin
acts as a filter and has a narrow frequency width, it can by
definition only analyse the energy within that band. It is by putting
together the bins that we get a meaningful global picture. Moreover
the resolution of the FFT analysis - i.e. the width of each band - is
dependent on the FFT size. The smaller the size the more generalised
the analytical function of the individual bins (but the less
generalised the time resolution). Of course one bin does not
necessarily correspond with one partial (however, it can on rare
occasions), I was never under this allusion. But then not every sound
can be successfully broken into individual partials as such. In the
real world I think of sine tones as band-limited noise rather than
'pure' frequency component. my personal experiments have demonstrated
to me that partial analysis/synthesis can only really work with
harmonic or simpler inharmonic sound sources, hence the need for the
residual part in the ATS analysis, which doesn't really give a
convincing result if you ask me.

Best,

Peiman


> If you were to encode a pure sine wave doing a slow upward glissando into fft data, the bins would show clusters of active frequencies that would move higher over time and would always be centered on the actual input pitch. The number of bins with significant content would change - spreading wider to encompass more bins as the frequency is between bins, narrowing as the frequency approaches the exact frequency of a bin. If the frequency and phase line up perfectly you may actually get a lucky moment where only one bin has significant data.
>
> If you were to decide that since it is only a single sine wave you can recreate it with a single bin, just picking the loudest bin at any moment, you would get a sound that jumps from one harmonic of the frequency step of the analysis to another, with no smooth sliding going on at all. And the amplitude would be very erratic, jumping higher as you approach a harmonic of your analysis' frequency step, and shrinking much lower when between them.
>
> Justin Glenn Smith wrote:
>> If you have an analysis size of 512, and sr of 44100, you have the following frequencies stored:
>> 0
>> 43.06640625
>> all of the harmonics of 43.06640625 hz that are below nyquist
>>
>> Nothing else, whatsoever.
>>
>> Frequencies that are not in that list are recreated during synthesis but not directly stored. They are generated by cancellations based on phase relationships between frequencies in that list. When you drop a large enough number of bins, 43.06640625 hz and its harmonics will dominate the result more and more.
>>
>> With transposition during resynthesis you are changing the phase cancellations evenly with the original pitches. Therefore your original spectrum comes through, in shifted form - the spectrum is shifted, but no spectral information is lost, you don't get arbitrary spectral distortion.
>>
>> I call the change that happens with dropping bins a distortion because it is doing something you likely don't want - not just filtering out part of the frequency content, but doing arbitrary frequency shifts, the nature of which are determined by the number of analysis bins and the sampling rate. I think that this can be mitigated by grabbing groups of adjacent frequencies around the biggest spectral peaks, rather than just grabbing the biggest peaks. Perhaps using an envelope, where the amplitude is decreased as one gets further from the peak in the spectrum would be helpful as well, but this is just a hypothesis, I haven't tried it.
>>
>> peiman khosravi wrote:
>>> Yes I read your emails a couple of times after sending that!
>>>
>>> I'm glad 2 and 3 give the same result! I am not sure if distortion is
>>> the right word here. Alterations for sure, but then you expect such
>>> alterations otherwise what's the point of processing.
>>>
>>> What do you mean by distortion exactly? Naturally if we kill a couple
>>> of bins we will not have the same sound as the original input signal.
>>> What I was referring to is that sort of blurring effect (loosing the
>>> transients) you get if you start messing with the frequency data of
>>> the bins. The bins do actually posses a frequency data right? This
>>> does not happen if you do not touch the frequency data (in my limited
>>> experience).
>>>
>>> Thanks
>>>
>>> Peiman
>>>
>>> On 17 January 2011 01:17, Justin Glenn Smith  wrote:
>>>> But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).
>>>>
>>>> 2 and 3 get you the same signal
>>>>
>>>> But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.
>>>>
>>>> The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.
>>>>
>>>> peiman khosravi wrote:
>>>>> Yes I get your point. I know that changing the frequency data of the
>>>>> FFT signal, which is not the same as the pure frequency data in your
>>>>> input signal (i.e. the partials) is a bad idea. My question was, would
>>>>> changing the amplitude values give you a distorted output?
>>>>>
>>>>> Let me rephrase it.
>>>>>
>>>>> 1- Say I have two audio channels. I now split my FFT bins into two
>>>>> groups, sending half the bins (amplitude and frequency pairs) to the
>>>>> first and the other half to the second channel.
>>>>> 2- I also make a version in which all the bins go into the same channel
>>>>> 3- now mix the two channels in the first version into a mono signal.
>>>>>
>>>>> The question is are you getting the same result in experiments #2 and 3?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Peiman
>>>>>
>>>>> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>>>>>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>>>>>
>>>>>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>>>>>
>>>>>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>>>>>
>>>>>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>>>>>
>>>>>> Justin Glenn Smith wrote:
>>>>>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>>>>>
>>>>>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>>>>>
>>>>>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>>>>>
>>>>>>> Aaron Krister Johnson wrote:
>>>>>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>>>>>> have to write a script in the language of one's choosing based on output
>>>>>>>> from pvlook?
>>>>>>>>
>>>>>>>> AKJ
>>>>>>>>
>>>>>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>>>>>> reached.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>>>>>
>>>>>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>>>>>> info it should already have, in effect?
>>>>>>>>>>
>>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>>>>>> csound"
>>>>>>>>>
>>>>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Trevor Wishart calls this process "tracing", and implemented it in the 
CDP process of that name. I incorporated the algorithm into one of the 
pvoc effects for the pvs-style plugin we did for Cakewalk years ago; it 
incurs very little processing cost (at least, compared to the analysis 
/resynthesis stages). That was such a long time ago I will have to look 
up the code to see exactly what he and I did. In any case, I think it 
would be a perfectly reasonable process to have as an opcode. I do not 
recall finding the process noticeably expensive in CPU terms.

Note that this is one of those proc processes where the contents of a 
frame can change frame by frame, as different bins contain the largest 
values and so turn on and off at the frame rate. This gives the familiar 
pvoc quasi-granular "bubbling" effect. Often this is all "part of the 
charm", but otherwise it will have to be followed by some sort of bin 
filtering stage ( "blur" etc) to smooth things out somewhat.

Richard Dobson



On 16/01/2011 23:53, Victor Lazzarini wrote:
> My thought on this is that it is possible, but it might be expensive.
> You will need to sort all bins by amp, until the number of requested
> bins is
> reached.
>
> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>
>> 4) is there a way to tell csound to pick, say, the 13 loudest bins
>> only...it seems like you have to tell it which bins you want, but what
>> if you don't know in advance, or want to make the decision based on
>> loudness, info it should already have, in effect?
>
>
>
> Send bugs reports to the Sourceforge bug tracker
> https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>




Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I often wondered whether it was an expensive operation because I could  
not figure out a cheap way of sorting bin amplitudes. Would you be  
able to tell us
the trick or is it secret? I never implemented it as a pvs opcode  
exactly because of that. But you could do it maybe?

Victor
On 17 Jan 2011, at 12:00, Richard Dobson wrote:

> Trevor Wishart calls this process "tracing", and implemented it in  
> the CDP process of that name. I incorporated the algorithm into one  
> of the pvoc effects for the pvs-style plugin we did for Cakewalk  
> years ago; it incurs very little processing cost (at least, compared  
> to the analysis /resynthesis stages). That was such a long time ago  
> I will have to look up the code to see exactly what he and I did. In  
> any case, I think it would be a perfectly reasonable process to have  
> as an opcode. I do not recall finding the process noticeably  
> expensive in CPU terms.
>
> Note that this is one of those proc processes where the contents of  
> a frame can change frame by frame, as different bins contain the  
> largest values and so turn on and off at the frame rate. This gives  
> the familiar pvoc quasi-granular "bubbling" effect. Often this is  
> all "part of the charm", but otherwise it will have to be followed  
> by some sort of bin filtering stage ( "blur" etc) to smooth things  
> out somewhat.
>
> Richard Dobson
>
>
>
> On 16/01/2011 23:53, Victor Lazzarini wrote:
>> My thought on this is that it is possible, but it might be expensive.
>> You will need to sort all bins by amp, until the number of requested
>> bins is
>> reached.
>>
>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>
>>> 4) is there a way to tell csound to pick, say, the 13 loudest bins
>>> only...it seems like you have to tell it which bins you want, but  
>>> what
>>> if you don't know in advance, or want to make the decision based on
>>> loudness, info it should already have, in effect?
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

For anyone on OS X. Michael Norris also has a set of free plug-ins
inspired by Trevor Wishart's writing. It includes tracing, shimmering
and so on. It would be nice to have some of these implemented in
Csound (as the pvs quality if far more superior). I think most of them
can be made into UDOs.

http://www.michaelnorris.info/software.html

P


On 17 January 2011 12:00, Richard Dobson  wrote:
> Trevor Wishart calls this process "tracing", and implemented it in the CDP
> process of that name. I incorporated the algorithm into one of the pvoc
> effects for the pvs-style plugin we did for Cakewalk years ago; it incurs
> very little processing cost (at least, compared to the analysis /resynthesis
> stages). That was such a long time ago I will have to look up the code to
> see exactly what he and I did. In any case, I think it would be a perfectly
> reasonable process to have as an opcode. I do not recall finding the process
> noticeably expensive in CPU terms.
>
> Note that this is one of those proc processes where the contents of a frame
> can change frame by frame, as different bins contain the largest values and
> so turn on and off at the frame rate. This gives the familiar pvoc
> quasi-granular "bubbling" effect. Often this is all "part of the charm", but
> otherwise it will have to be followed by some sort of bin filtering stage (
> "blur" etc) to smooth things out somewhat.
>
> Richard Dobson
>
>
>
> On 16/01/2011 23:53, Victor Lazzarini wrote:
>>
>> My thought on this is that it is possible, but it might be expensive.
>> You will need to sort all bins by amp, until the number of requested
>> bins is
>> reached.
>>
>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>
>>> 4) is there a way to tell csound to pick, say, the 13 loudest bins
>>> only...it seems like you have to tell it which bins you want, but what
>>> if you don't know in advance, or want to make the decision based on
>>> loudness, info it should already have, in effect?
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

But doesn't pvstencil already do this if the table contains a flat
line and the gain value is set to zero??

I find that I can do all sorts of complex operations on individual
bins, at 96khz sr and with 6 outputs before the computer begins to
hiccup.

P

On 17 January 2011 12:10, Victor Lazzarini  wrote:
> I often wondered whether it was an expensive operation because I could not
> figure out a cheap way of sorting bin amplitudes. Would you be able to tell
> us
> the trick or is it secret? I never implemented it as a pvs opcode exactly
> because of that. But you could do it maybe?
>
> Victor
> On 17 Jan 2011, at 12:00, Richard Dobson wrote:
>
>> Trevor Wishart calls this process "tracing", and implemented it in the CDP
>> process of that name. I incorporated the algorithm into one of the pvoc
>> effects for the pvs-style plugin we did for Cakewalk years ago; it incurs
>> very little processing cost (at least, compared to the analysis /resynthesis
>> stages). That was such a long time ago I will have to look up the code to
>> see exactly what he and I did. In any case, I think it would be a perfectly
>> reasonable process to have as an opcode. I do not recall finding the process
>> noticeably expensive in CPU terms.
>>
>> Note that this is one of those proc processes where the contents of a
>> frame can change frame by frame, as different bins contain the largest
>> values and so turn on and off at the frame rate. This gives the familiar
>> pvoc quasi-granular "bubbling" effect. Often this is all "part of the
>> charm", but otherwise it will have to be followed by some sort of bin
>> filtering stage ( "blur" etc) to smooth things out somewhat.
>>
>> Richard Dobson
>>
>>
>>
>> On 16/01/2011 23:53, Victor Lazzarini wrote:
>>>
>>> My thought on this is that it is possible, but it might be expensive.
>>> You will need to sort all bins by amp, until the number of requested
>>> bins is
>>> reached.
>>>
>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>
>>>> 4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>> only...it seems like you have to tell it which bins you want, but what
>>>> if you don't know in advance, or want to make the decision based on
>>>> loudness, info it should already have, in effect?
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

It will do thresholding, but you will not be able to say 'keep 10  
loudest bins' etc

Victor
On 17 Jan 2011, at 12:14, peiman khosravi wrote:

> But doesn't pvstencil already do this if the table contains a flat
> line and the gain value is set to zero??
>
> I find that I can do all sorts of complex operations on individual
> bins, at 96khz sr and with 6 outputs before the computer begins to
> hiccup.
>
> P
>
> On 17 January 2011 12:10, Victor Lazzarini  
>  wrote:
>> I often wondered whether it was an expensive operation because I  
>> could not
>> figure out a cheap way of sorting bin amplitudes. Would you be able  
>> to tell
>> us
>> the trick or is it secret? I never implemented it as a pvs opcode  
>> exactly
>> because of that. But you could do it maybe?
>>
>> Victor
>> On 17 Jan 2011, at 12:00, Richard Dobson wrote:
>>
>>> Trevor Wishart calls this process "tracing", and implemented it in  
>>> the CDP
>>> process of that name. I incorporated the algorithm into one of the  
>>> pvoc
>>> effects for the pvs-style plugin we did for Cakewalk years ago; it  
>>> incurs
>>> very little processing cost (at least, compared to the analysis / 
>>> resynthesis
>>> stages). That was such a long time ago I will have to look up the  
>>> code to
>>> see exactly what he and I did. In any case, I think it would be a  
>>> perfectly
>>> reasonable process to have as an opcode. I do not recall finding  
>>> the process
>>> noticeably expensive in CPU terms.
>>>
>>> Note that this is one of those proc processes where the contents  
>>> of a
>>> frame can change frame by frame, as different bins contain the  
>>> largest
>>> values and so turn on and off at the frame rate. This gives the  
>>> familiar
>>> pvoc quasi-granular "bubbling" effect. Often this is all "part of  
>>> the
>>> charm", but otherwise it will have to be followed by some sort of  
>>> bin
>>> filtering stage ( "blur" etc) to smooth things out somewhat.
>>>
>>> Richard Dobson
>>>
>>>
>>>
>>> On 16/01/2011 23:53, Victor Lazzarini wrote:
>>>>
>>>> My thought on this is that it is possible, but it might be  
>>>> expensive.
>>>> You will need to sort all bins by amp, until the number of  
>>>> requested
>>>> bins is
>>>> reached.
>>>>
>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>
>>>>> 4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>> only...it seems like you have to tell it which bins you want,  
>>>>> but what
>>>>> if you don't know in advance, or want to make the decision based  
>>>>> on
>>>>> loudness, info it should already have, in effect?
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Ah yes I see. Makes sense.

P



On 17 January 2011 12:17, Victor Lazzarini  wrote:
> It will do thresholding, but you will not be able to say 'keep 10 loudest
> bins' etc
>
> Victor
> On 17 Jan 2011, at 12:14, peiman khosravi wrote:
>
>> But doesn't pvstencil already do this if the table contains a flat
>> line and the gain value is set to zero??
>>
>> I find that I can do all sorts of complex operations on individual
>> bins, at 96khz sr and with 6 outputs before the computer begins to
>> hiccup.
>>
>> P
>>
>> On 17 January 2011 12:10, Victor Lazzarini 
>> wrote:
>>>
>>> I often wondered whether it was an expensive operation because I could
>>> not
>>> figure out a cheap way of sorting bin amplitudes. Would you be able to
>>> tell
>>> us
>>> the trick or is it secret? I never implemented it as a pvs opcode exactly
>>> because of that. But you could do it maybe?
>>>
>>> Victor
>>> On 17 Jan 2011, at 12:00, Richard Dobson wrote:
>>>
>>>> Trevor Wishart calls this process "tracing", and implemented it in the
>>>> CDP
>>>> process of that name. I incorporated the algorithm into one of the pvoc
>>>> effects for the pvs-style plugin we did for Cakewalk years ago; it
>>>> incurs
>>>> very little processing cost (at least, compared to the analysis
>>>> /resynthesis
>>>> stages). That was such a long time ago I will have to look up the code
>>>> to
>>>> see exactly what he and I did. In any case, I think it would be a
>>>> perfectly
>>>> reasonable process to have as an opcode. I do not recall finding the
>>>> process
>>>> noticeably expensive in CPU terms.
>>>>
>>>> Note that this is one of those proc processes where the contents of a
>>>> frame can change frame by frame, as different bins contain the largest
>>>> values and so turn on and off at the frame rate. This gives the familiar
>>>> pvoc quasi-granular "bubbling" effect. Often this is all "part of the
>>>> charm", but otherwise it will have to be followed by some sort of bin
>>>> filtering stage ( "blur" etc) to smooth things out somewhat.
>>>>
>>>> Richard Dobson
>>>>
>>>>
>>>>
>>>> On 16/01/2011 23:53, Victor Lazzarini wrote:
>>>>>
>>>>> My thought on this is that it is possible, but it might be expensive.
>>>>> You will need to sort all bins by amp, until the number of requested
>>>>> bins is
>>>>> reached.
>>>>>
>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>
>>>>>> 4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>> only...it seems like you have to tell it which bins you want, but what
>>>>>> if you don't know in advance, or want to make the decision based on
>>>>>> loudness, info it should already have, in effect?
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>         https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 17/01/2011 12:10, Victor Lazzarini wrote:
> I often wondered whether it was an expensive operation because I could
> not figure out a cheap way of sorting bin amplitudes. Would you be able
> to tell us
> the trick or is it secret? I never implemented it as a pvs opcode
> exactly because of that. But you could do it maybe?
>


He uses a circular linked list, dynamically expanding and contracting, 
and is otherwise fairly brute-force - iterating through the array. I 
have never analysed it closely, so can't say much more about it. One 
issue from a real-time point of view is that there is some dynamic 
allocation/freeing of memory. All I can say is "we got away with it" in 
our DirectSound plugin; but of course it really needs an implementation 
that doesn't block in a real-time context (e.g. an internal private 
memory pool and allocator). So his code may in the end not be the model 
to follow to meet modern requirements. Actually, I think vanilla 
qsorting on what is a relatively small array would not be such an issue 
these days.  I just don't know when I would find the time - still fully 
engaged with LHCsound at present!

Richard Dobson



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Could the dynamic-linked list be replaced by a static array? Then it's  
just qsorting, is it not?

Victor

On 17 Jan 2011, at 13:17, Richard Dobson wrote:

> On 17/01/2011 12:10, Victor Lazzarini wrote:
>> I often wondered whether it was an expensive operation because I  
>> could
>> not figure out a cheap way of sorting bin amplitudes. Would you be  
>> able
>> to tell us
>> the trick or is it secret? I never implemented it as a pvs opcode
>> exactly because of that. But you could do it maybe?
>>
>
>
> He uses a circular linked list, dynamically expanding and  
> contracting, and is otherwise fairly brute-force - iterating through  
> the array. I have never analysed it closely, so can't say much more  
> about it. One issue from a real-time point of view is that there is  
> some dynamic allocation/freeing of memory. All I can say is "we got  
> away with it" in our DirectSound plugin; but of course it really  
> needs an implementation that doesn't block in a real-time context  
> (e.g. an internal private memory pool and allocator). So his code  
> may in the end not be the model to follow to meet modern  
> requirements. Actually, I think vanilla qsorting on what is a  
> relatively small array would not be such an issue these days.  I  
> just don't know when I would find the time - still fully engaged  
> with LHCsound at present!
>
> Richard Dobson
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 17/01/2011 13:24, Victor Lazzarini wrote:
> Could the dynamic-linked list be replaced by a static array? Then it's
> just qsorting, is it not?
>

Seems reasonable to me.

Richard



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

cool stuff - thanks for the tip!
	joachim

Am 17.01.2011 13:11, schrieb peiman khosravi:
> For anyone on OS X. Michael Norris also has a set of free plug-ins
> inspired by Trevor Wishart's writing. It includes tracing, shimmering
> and so on. It would be nice to have some of these implemented in
> Csound (as the pvs quality if far more superior). I think most of them
> can be made into UDOs.
> 
> http://www.michaelnorris.info/software.html
> 
> P
> 
> 
> On 17 January 2011 12:00, Richard Dobson  wrote:
>> Trevor Wishart calls this process "tracing", and implemented it in the CDP
>> process of that name. I incorporated the algorithm into one of the pvoc
>> effects for the pvs-style plugin we did for Cakewalk years ago; it incurs
>> very little processing cost (at least, compared to the analysis /resynthesis
>> stages). That was such a long time ago I will have to look up the code to
>> see exactly what he and I did. In any case, I think it would be a perfectly
>> reasonable process to have as an opcode. I do not recall finding the process
>> noticeably expensive in CPU terms.
>>
>> Note that this is one of those proc processes where the contents of a frame
>> can change frame by frame, as different bins contain the largest values and
>> so turn on and off at the frame rate. This gives the familiar pvoc
>> quasi-granular "bubbling" effect. Often this is all "part of the charm", but
>> otherwise it will have to be followed by some sort of bin filtering stage (
>> "blur" etc) to smooth things out somewhat.
>>
>> Richard Dobson
>>
>>
>>
>> On 16/01/2011 23:53, Victor Lazzarini wrote:
>>>
>>> My thought on this is that it is possible, but it might be expensive.
>>> You will need to sort all bins by amp, until the number of requested
>>> bins is
>>> reached.
>>>
>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>
>>>> 4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>> only...it seems like you have to tell it which bins you want, but what
>>>> if you don't know in advance, or want to make the decision based on
>>>> loudness, info it should already have, in effect?
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

But the bins only encode pure frequencies, they don't encode bands or regions.

Any sound can be decomposed into a set of frequencies and exactly reproduced from that decomposition (not just perceptually identical, the same exact waveform can be reproduced if you are willing to expend the CPU power, mind you csound likely cuts some corners for efficiency reasons that prevent this kind of exact reproduction). The frequencies don't have to be related to the input sound at all (and typically won't be), they only need to obey certain mathematical relations to one another.

Relative bands of strength as you describe is the amount of precision you have left if you modify the bins independently of one another. This is when you start to hear less of the input sound, and more of the analysis method. This is not "blurring" (which to me connotes some kind of averaging or filling in of the input), it is frequency aliasing, it is replacing the input frequencies with other nearby frequencies that happen to have been the analysis frequencies.

peiman khosravi wrote:
> On 17 January 2011 02:17, Justin Glenn Smith  wrote:
>> Oh, and a more direct reply to your question "the bins do actually posses a frequency data right?": they contain the data implicitly, it is calculated based on the number of analysis bins and the sampling rate - the bins are divided into equal numbers of hz starting with 0 and going up to nyquist. And the frequency data is a convention shared between analysis and resynthesis - the frequencies represented by the bins are determined solely by the number of bins and the sampling rate, and have nothing to do with the input sound.
>>
> 
> To look at it differently one could say that the bins show the
> relative energy of the sound within the frequency continuum. Each bin
> acts as a filter and has a narrow frequency width, it can by
> definition only analyse the energy within that band. It is by putting
> together the bins that we get a meaningful global picture. Moreover
> the resolution of the FFT analysis - i.e. the width of each band - is
> dependent on the FFT size. The smaller the size the more generalised
> the analytical function of the individual bins (but the less
> generalised the time resolution). Of course one bin does not
> necessarily correspond with one partial (however, it can on rare
> occasions), I was never under this allusion. But then not every sound
> can be successfully broken into individual partials as such. In the
> real world I think of sine tones as band-limited noise rather than
> 'pure' frequency component. my personal experiments have demonstrated
> to me that partial analysis/synthesis can only really work with
> harmonic or simpler inharmonic sound sources, hence the need for the
> residual part in the ATS analysis, which doesn't really give a
> convincing result if you ask me.
> 
> Best,
> 
> Peiman
> 
> 
>> If you were to encode a pure sine wave doing a slow upward glissando into fft data, the bins would show clusters of active frequencies that would move higher over time and would always be centered on the actual input pitch. The number of bins with significant content would change - spreading wider to encompass more bins as the frequency is between bins, narrowing as the frequency approaches the exact frequency of a bin. If the frequency and phase line up perfectly you may actually get a lucky moment where only one bin has significant data.
>>
>> If you were to decide that since it is only a single sine wave you can recreate it with a single bin, just picking the loudest bin at any moment, you would get a sound that jumps from one harmonic of the frequency step of the analysis to another, with no smooth sliding going on at all. And the amplitude would be very erratic, jumping higher as you approach a harmonic of your analysis' frequency step, and shrinking much lower when between them.
>>
>> Justin Glenn Smith wrote:
>>> If you have an analysis size of 512, and sr of 44100, you have the following frequencies stored:
>>> 0
>>> 43.06640625
>>> all of the harmonics of 43.06640625 hz that are below nyquist
>>>
>>> Nothing else, whatsoever.
>>>
>>> Frequencies that are not in that list are recreated during synthesis but not directly stored. They are generated by cancellations based on phase relationships between frequencies in that list. When you drop a large enough number of bins, 43.06640625 hz and its harmonics will dominate the result more and more.
>>>
>>> With transposition during resynthesis you are changing the phase cancellations evenly with the original pitches. Therefore your original spectrum comes through, in shifted form - the spectrum is shifted, but no spectral information is lost, you don't get arbitrary spectral distortion.
>>>
>>> I call the change that happens with dropping bins a distortion because it is doing something you likely don't want - not just filtering out part of the frequency content, but doing arbitrary frequency shifts, the nature of which are determined by the number of analysis bins and the sampling rate. I think that this can be mitigated by grabbing groups of adjacent frequencies around the biggest spectral peaks, rather than just grabbing the biggest peaks. Perhaps using an envelope, where the amplitude is decreased as one gets further from the peak in the spectrum would be helpful as well, but this is just a hypothesis, I haven't tried it.
>>>
>>> peiman khosravi wrote:
>>>> Yes I read your emails a couple of times after sending that!
>>>>
>>>> I'm glad 2 and 3 give the same result! I am not sure if distortion is
>>>> the right word here. Alterations for sure, but then you expect such
>>>> alterations otherwise what's the point of processing.
>>>>
>>>> What do you mean by distortion exactly? Naturally if we kill a couple
>>>> of bins we will not have the same sound as the original input signal.
>>>> What I was referring to is that sort of blurring effect (loosing the
>>>> transients) you get if you start messing with the frequency data of
>>>> the bins. The bins do actually posses a frequency data right? This
>>>> does not happen if you do not touch the frequency data (in my limited
>>>> experience).
>>>>
>>>> Thanks
>>>>
>>>> Peiman
>>>>
>>>> On 17 January 2011 01:17, Justin Glenn Smith  wrote:
>>>>> But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).
>>>>>
>>>>> 2 and 3 get you the same signal
>>>>>
>>>>> But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.
>>>>>
>>>>> The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.
>>>>>
>>>>> peiman khosravi wrote:
>>>>>> Yes I get your point. I know that changing the frequency data of the
>>>>>> FFT signal, which is not the same as the pure frequency data in your
>>>>>> input signal (i.e. the partials) is a bad idea. My question was, would
>>>>>> changing the amplitude values give you a distorted output?
>>>>>>
>>>>>> Let me rephrase it.
>>>>>>
>>>>>> 1- Say I have two audio channels. I now split my FFT bins into two
>>>>>> groups, sending half the bins (amplitude and frequency pairs) to the
>>>>>> first and the other half to the second channel.
>>>>>> 2- I also make a version in which all the bins go into the same channel
>>>>>> 3- now mix the two channels in the first version into a mono signal.
>>>>>>
>>>>>> The question is are you getting the same result in experiments #2 and 3?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Peiman
>>>>>>
>>>>>> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>>>>>>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>>>>>>
>>>>>>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>>>>>>
>>>>>>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>>>>>>
>>>>>>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>>>>>>
>>>>>>> Justin Glenn Smith wrote:
>>>>>>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>>>>>>
>>>>>>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>>>>>>
>>>>>>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>>>>>>
>>>>>>>> Aaron Krister Johnson wrote:
>>>>>>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>>>>>>> have to write a script in the language of one's choosing based on output
>>>>>>>>> from pvlook?
>>>>>>>>>
>>>>>>>>> AKJ
>>>>>>>>>
>>>>>>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>>>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>>>>>>> reached.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>>>>>>
>>>>>>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>>>>>>> info it should already have, in effect?
>>>>>>>>>>>
>>>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>>>>>>> csound"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>
>>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

OK but I still don't understand.

If I analyse a sine-tone at 440 and print out the fft frequency data I
get bin frequencies around the 440 region. So there is a direct
relationship between the analysis data and the input sound even though
you actually need all the bins to synthesise the input sound correctly
(all the bands around the center frequency are added up to create the
partial). What I mean is that the bins show that the spectral energy
of the input sound is concentrated around 440, give or take. The
actual precision (resolution) depends on the FFT size. And you can see
this direct relationship on a sonogram right (see attached)? Am I
being really daft?

Best,

Peiman

On 17 January 2011 17:04, Justin Glenn Smith  wrote:
> But the bins only encode pure frequencies, they don't encode bands or regions.
>
> Any sound can be decomposed into a set of frequencies and exactly reproduced from that decomposition (not just perceptually identical, the same exact waveform can be reproduced if you are willing to expend the CPU power, mind you csound likely cuts some corners for efficiency reasons that prevent this kind of exact reproduction). The frequencies don't have to be related to the input sound at all (and typically won't be), they only need to obey certain mathematical relations to one another.
>
> Relative bands of strength as you describe is the amount of precision you have left if you modify the bins independently of one another. This is when you start to hear less of the input sound, and more of the analysis method. This is not "blurring" (which to me connotes some kind of averaging or filling in of the input), it is frequency aliasing, it is replacing the input frequencies with other nearby frequencies that happen to have been the analysis frequencies.
>
> peiman khosravi wrote:
>> On 17 January 2011 02:17, Justin Glenn Smith  wrote:
>>> Oh, and a more direct reply to your question "the bins do actually posses a frequency data right?": they contain the data implicitly, it is calculated based on the number of analysis bins and the sampling rate - the bins are divided into equal numbers of hz starting with 0 and going up to nyquist. And the frequency data is a convention shared between analysis and resynthesis - the frequencies represented by the bins are determined solely by the number of bins and the sampling rate, and have nothing to do with the input sound.
>>>
>>
>> To look at it differently one could say that the bins show the
>> relative energy of the sound within the frequency continuum. Each bin
>> acts as a filter and has a narrow frequency width, it can by
>> definition only analyse the energy within that band. It is by putting
>> together the bins that we get a meaningful global picture. Moreover
>> the resolution of the FFT analysis - i.e. the width of each band - is
>> dependent on the FFT size. The smaller the size the more generalised
>> the analytical function of the individual bins (but the less
>> generalised the time resolution). Of course one bin does not
>> necessarily correspond with one partial (however, it can on rare
>> occasions), I was never under this allusion. But then not every sound
>> can be successfully broken into individual partials as such. In the
>> real world I think of sine tones as band-limited noise rather than
>> 'pure' frequency component. my personal experiments have demonstrated
>> to me that partial analysis/synthesis can only really work with
>> harmonic or simpler inharmonic sound sources, hence the need for the
>> residual part in the ATS analysis, which doesn't really give a
>> convincing result if you ask me.
>>
>> Best,
>>
>> Peiman
>>
>>
>>> If you were to encode a pure sine wave doing a slow upward glissando into fft data, the bins would show clusters of active frequencies that would move higher over time and would always be centered on the actual input pitch. The number of bins with significant content would change - spreading wider to encompass more bins as the frequency is between bins, narrowing as the frequency approaches the exact frequency of a bin. If the frequency and phase line up perfectly you may actually get a lucky moment where only one bin has significant data.
>>>
>>> If you were to decide that since it is only a single sine wave you can recreate it with a single bin, just picking the loudest bin at any moment, you would get a sound that jumps from one harmonic of the frequency step of the analysis to another, with no smooth sliding going on at all. And the amplitude would be very erratic, jumping higher as you approach a harmonic of your analysis' frequency step, and shrinking much lower when between them.
>>>
>>> Justin Glenn Smith wrote:
>>>> If you have an analysis size of 512, and sr of 44100, you have the following frequencies stored:
>>>> 0
>>>> 43.06640625
>>>> all of the harmonics of 43.06640625 hz that are below nyquist
>>>>
>>>> Nothing else, whatsoever.
>>>>
>>>> Frequencies that are not in that list are recreated during synthesis but not directly stored. They are generated by cancellations based on phase relationships between frequencies in that list. When you drop a large enough number of bins, 43.06640625 hz and its harmonics will dominate the result more and more.
>>>>
>>>> With transposition during resynthesis you are changing the phase cancellations evenly with the original pitches. Therefore your original spectrum comes through, in shifted form - the spectrum is shifted, but no spectral information is lost, you don't get arbitrary spectral distortion.
>>>>
>>>> I call the change that happens with dropping bins a distortion because it is doing something you likely don't want - not just filtering out part of the frequency content, but doing arbitrary frequency shifts, the nature of which are determined by the number of analysis bins and the sampling rate. I think that this can be mitigated by grabbing groups of adjacent frequencies around the biggest spectral peaks, rather than just grabbing the biggest peaks. Perhaps using an envelope, where the amplitude is decreased as one gets further from the peak in the spectrum would be helpful as well, but this is just a hypothesis, I haven't tried it.
>>>>
>>>> peiman khosravi wrote:
>>>>> Yes I read your emails a couple of times after sending that!
>>>>>
>>>>> I'm glad 2 and 3 give the same result! I am not sure if distortion is
>>>>> the right word here. Alterations for sure, but then you expect such
>>>>> alterations otherwise what's the point of processing.
>>>>>
>>>>> What do you mean by distortion exactly? Naturally if we kill a couple
>>>>> of bins we will not have the same sound as the original input signal.
>>>>> What I was referring to is that sort of blurring effect (loosing the
>>>>> transients) you get if you start messing with the frequency data of
>>>>> the bins. The bins do actually posses a frequency data right? This
>>>>> does not happen if you do not touch the frequency data (in my limited
>>>>> experience).
>>>>>
>>>>> Thanks
>>>>>
>>>>> Peiman
>>>>>
>>>>> On 17 January 2011 01:17, Justin Glenn Smith  wrote:
>>>>>> But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).
>>>>>>
>>>>>> 2 and 3 get you the same signal
>>>>>>
>>>>>> But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.
>>>>>>
>>>>>> The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.
>>>>>>
>>>>>> peiman khosravi wrote:
>>>>>>> Yes I get your point. I know that changing the frequency data of the
>>>>>>> FFT signal, which is not the same as the pure frequency data in your
>>>>>>> input signal (i.e. the partials) is a bad idea. My question was, would
>>>>>>> changing the amplitude values give you a distorted output?
>>>>>>>
>>>>>>> Let me rephrase it.
>>>>>>>
>>>>>>> 1- Say I have two audio channels. I now split my FFT bins into two
>>>>>>> groups, sending half the bins (amplitude and frequency pairs) to the
>>>>>>> first and the other half to the second channel.
>>>>>>> 2- I also make a version in which all the bins go into the same channel
>>>>>>> 3- now mix the two channels in the first version into a mono signal.
>>>>>>>
>>>>>>> The question is are you getting the same result in experiments #2 and 3?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Peiman
>>>>>>>
>>>>>>> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>>>>>>>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>>>>>>>
>>>>>>>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>>>>>>>
>>>>>>>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>>>>>>>
>>>>>>>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>>>>>>>
>>>>>>>> Justin Glenn Smith wrote:
>>>>>>>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>>>>>>>
>>>>>>>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>>>>>>>
>>>>>>>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>>>>>>>
>>>>>>>>> Aaron Krister Johnson wrote:
>>>>>>>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>>>>>>>> have to write a script in the language of one's choosing based on output
>>>>>>>>>> from pvlook?
>>>>>>>>>>
>>>>>>>>>> AKJ
>>>>>>>>>>
>>>>>>>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>>>>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>>>>>>>> reached.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>>>>>>>
>>>>>>>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>>>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>>>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>>>>>>>> info it should already have, in effect?
>>>>>>>>>>>>
>>>>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>>>>>>>> csound"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>
>>>>>>>>
>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>
>>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

peiman khosravi wrote:
> OK but I still don't understand.
> 
> If I analyse a sine-tone at 440 and print out the fft frequency data I
> get bin frequencies around the 440 region. So there is a direct
> relationship between the analysis data and the input sound even though
> you actually need all the bins to synthesise the input sound correctly
> (all the bands around the center frequency are added up to create the
> partial). What I mean is that the bins show that the spectral energy
> of the input sound is concentrated around 440, give or take. The
Yes

> actual precision (resolution) depends on the FFT size. And you can see
> this direct relationship on a sonogram right (see attached)? Am I
> being really daft?

No, you are not, it seems we actually understand each other here.

Do note the visual information can be misleading - there is only energy in one exact place (440), and it is nigh impossible for a human to look at that data representation and differentiate from a smeared frequency band (though our ears can hear the difference and the fft data does encode it accurtely as an amalgalm of frequency / phase / amplitude - probably impossible to intelligibly graph).

The precision is in terms of time vs. frequency data for further usage - a larger size or a smaller one are both capable of exactly reproducing your data if unmodified, smaller gives better time info for further processing, larger gives better frequency info. And if any information losing CPU saving shortcuts are made, and/or you modify the data before resynthesizing, larger and smaller sizes give very different kinds of aliasing.

I am really feeling like a pedant now, but it was helpful for me to finally understand the limitations of fft and why my data so quickly turned to a distorted mess - it isn't because fft is imprecise, but because I was using the data in a way that discarded important parts of the signal.

> 
> Best,
> 
> Peiman
> 
> On 17 January 2011 17:04, Justin Glenn Smith  wrote:
>> But the bins only encode pure frequencies, they don't encode bands or regions.
>>
>> Any sound can be decomposed into a set of frequencies and exactly reproduced from that decomposition (not just perceptually identical, the same exact waveform can be reproduced if you are willing to expend the CPU power, mind you csound likely cuts some corners for efficiency reasons that prevent this kind of exact reproduction). The frequencies don't have to be related to the input sound at all (and typically won't be), they only need to obey certain mathematical relations to one another.
>>
>> Relative bands of strength as you describe is the amount of precision you have left if you modify the bins independently of one another. This is when you start to hear less of the input sound, and more of the analysis method. This is not "blurring" (which to me connotes some kind of averaging or filling in of the input), it is frequency aliasing, it is replacing the input frequencies with other nearby frequencies that happen to have been the analysis frequencies.
>>
>> peiman khosravi wrote:
>>> On 17 January 2011 02:17, Justin Glenn Smith  wrote:
>>>> Oh, and a more direct reply to your question "the bins do actually posses a frequency data right?": they contain the data implicitly, it is calculated based on the number of analysis bins and the sampling rate - the bins are divided into equal numbers of hz starting with 0 and going up to nyquist. And the frequency data is a convention shared between analysis and resynthesis - the frequencies represented by the bins are determined solely by the number of bins and the sampling rate, and have nothing to do with the input sound.
>>>>
>>> To look at it differently one could say that the bins show the
>>> relative energy of the sound within the frequency continuum. Each bin
>>> acts as a filter and has a narrow frequency width, it can by
>>> definition only analyse the energy within that band. It is by putting
>>> together the bins that we get a meaningful global picture. Moreover
>>> the resolution of the FFT analysis - i.e. the width of each band - is
>>> dependent on the FFT size. The smaller the size the more generalised
>>> the analytical function of the individual bins (but the less
>>> generalised the time resolution). Of course one bin does not
>>> necessarily correspond with one partial (however, it can on rare
>>> occasions), I was never under this allusion. But then not every sound
>>> can be successfully broken into individual partials as such. In the
>>> real world I think of sine tones as band-limited noise rather than
>>> 'pure' frequency component. my personal experiments have demonstrated
>>> to me that partial analysis/synthesis can only really work with
>>> harmonic or simpler inharmonic sound sources, hence the need for the
>>> residual part in the ATS analysis, which doesn't really give a
>>> convincing result if you ask me.
>>>
>>> Best,
>>>
>>> Peiman
>>>
>>>
>>>> If you were to encode a pure sine wave doing a slow upward glissando into fft data, the bins would show clusters of active frequencies that would move higher over time and would always be centered on the actual input pitch. The number of bins with significant content would change - spreading wider to encompass more bins as the frequency is between bins, narrowing as the frequency approaches the exact frequency of a bin. If the frequency and phase line up perfectly you may actually get a lucky moment where only one bin has significant data.
>>>>
>>>> If you were to decide that since it is only a single sine wave you can recreate it with a single bin, just picking the loudest bin at any moment, you would get a sound that jumps from one harmonic of the frequency step of the analysis to another, with no smooth sliding going on at all. And the amplitude would be very erratic, jumping higher as you approach a harmonic of your analysis' frequency step, and shrinking much lower when between them.
>>>>
>>>> Justin Glenn Smith wrote:
>>>>> If you have an analysis size of 512, and sr of 44100, you have the following frequencies stored:
>>>>> 0
>>>>> 43.06640625
>>>>> all of the harmonics of 43.06640625 hz that are below nyquist
>>>>>
>>>>> Nothing else, whatsoever.
>>>>>
>>>>> Frequencies that are not in that list are recreated during synthesis but not directly stored. They are generated by cancellations based on phase relationships between frequencies in that list. When you drop a large enough number of bins, 43.06640625 hz and its harmonics will dominate the result more and more.
>>>>>
>>>>> With transposition during resynthesis you are changing the phase cancellations evenly with the original pitches. Therefore your original spectrum comes through, in shifted form - the spectrum is shifted, but no spectral information is lost, you don't get arbitrary spectral distortion.
>>>>>
>>>>> I call the change that happens with dropping bins a distortion because it is doing something you likely don't want - not just filtering out part of the frequency content, but doing arbitrary frequency shifts, the nature of which are determined by the number of analysis bins and the sampling rate. I think that this can be mitigated by grabbing groups of adjacent frequencies around the biggest spectral peaks, rather than just grabbing the biggest peaks. Perhaps using an envelope, where the amplitude is decreased as one gets further from the peak in the spectrum would be helpful as well, but this is just a hypothesis, I haven't tried it.
>>>>>
>>>>> peiman khosravi wrote:
>>>>>> Yes I read your emails a couple of times after sending that!
>>>>>>
>>>>>> I'm glad 2 and 3 give the same result! I am not sure if distortion is
>>>>>> the right word here. Alterations for sure, but then you expect such
>>>>>> alterations otherwise what's the point of processing.
>>>>>>
>>>>>> What do you mean by distortion exactly? Naturally if we kill a couple
>>>>>> of bins we will not have the same sound as the original input signal.
>>>>>> What I was referring to is that sort of blurring effect (loosing the
>>>>>> transients) you get if you start messing with the frequency data of
>>>>>> the bins. The bins do actually posses a frequency data right? This
>>>>>> does not happen if you do not touch the frequency data (in my limited
>>>>>> experience).
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Peiman
>>>>>>
>>>>>> On 17 January 2011 01:17, Justin Glenn Smith  wrote:
>>>>>>> But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).
>>>>>>>
>>>>>>> 2 and 3 get you the same signal
>>>>>>>
>>>>>>> But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.
>>>>>>>
>>>>>>> The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.
>>>>>>>
>>>>>>> peiman khosravi wrote:
>>>>>>>> Yes I get your point. I know that changing the frequency data of the
>>>>>>>> FFT signal, which is not the same as the pure frequency data in your
>>>>>>>> input signal (i.e. the partials) is a bad idea. My question was, would
>>>>>>>> changing the amplitude values give you a distorted output?
>>>>>>>>
>>>>>>>> Let me rephrase it.
>>>>>>>>
>>>>>>>> 1- Say I have two audio channels. I now split my FFT bins into two
>>>>>>>> groups, sending half the bins (amplitude and frequency pairs) to the
>>>>>>>> first and the other half to the second channel.
>>>>>>>> 2- I also make a version in which all the bins go into the same channel
>>>>>>>> 3- now mix the two channels in the first version into a mono signal.
>>>>>>>>
>>>>>>>> The question is are you getting the same result in experiments #2 and 3?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Peiman
>>>>>>>>
>>>>>>>> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>>>>>>>>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>>>>>>>>
>>>>>>>>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>>>>>>>>
>>>>>>>>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>>>>>>>>
>>>>>>>>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>>>>>>>>
>>>>>>>>> Justin Glenn Smith wrote:
>>>>>>>>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>>>>>>>>
>>>>>>>>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>>>>>>>>
>>>>>>>>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>>>>>>>>
>>>>>>>>>> Aaron Krister Johnson wrote:
>>>>>>>>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>>>>>>>>> have to write a script in the language of one's choosing based on output
>>>>>>>>>>> from pvlook?
>>>>>>>>>>>
>>>>>>>>>>> AKJ
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>>>>>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>>>>>>>>> reached.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>>>>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>>>>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>>>>>>>>> info it should already have, in effect?
>>>>>>>>>>>>>
>>>>>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>>>>>>>>> csound"
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>
>>>>>>>>
>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>
>>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 
> 
> ------------------------------------------------------------------------
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 17 January 2011 20:25, Justin Glenn Smith  wrote:

> I am really feeling like a pedant now, but it was helpful for me to finally understand the limitations of fft and why my data so quickly turned to a distorted mess - it isn't because fft is imprecise, but because I was using the data in a way that discarded important parts of the signal.
>
Not at all. I see your point. I have not been bothered by such
distortions in the past simply because I have avoided them through
careful processing, always listening and not accepting a result in
which the FFT analysis is not more or less invisible. The artifacts
can actually be tamed to create rather interesting results but it take
considerable effort and time to make sure it doesn't sound just like
another FFT artifact.

Thanks very much for the explanation. It is good to know the technical
reason behind the issue.

Best,

Peiman

>>
>> Best,
>>
>> Peiman
>>
>> On 17 January 2011 17:04, Justin Glenn Smith  wrote:
>>> But the bins only encode pure frequencies, they don't encode bands or regions.
>>>
>>> Any sound can be decomposed into a set of frequencies and exactly reproduced from that decomposition (not just perceptually identical, the same exact waveform can be reproduced if you are willing to expend the CPU power, mind you csound likely cuts some corners for efficiency reasons that prevent this kind of exact reproduction). The frequencies don't have to be related to the input sound at all (and typically won't be), they only need to obey certain mathematical relations to one another.
>>>
>>> Relative bands of strength as you describe is the amount of precision you have left if you modify the bins independently of one another. This is when you start to hear less of the input sound, and more of the analysis method. This is not "blurring" (which to me connotes some kind of averaging or filling in of the input), it is frequency aliasing, it is replacing the input frequencies with other nearby frequencies that happen to have been the analysis frequencies.
>>>
>>> peiman khosravi wrote:
>>>> On 17 January 2011 02:17, Justin Glenn Smith  wrote:
>>>>> Oh, and a more direct reply to your question "the bins do actually posses a frequency data right?": they contain the data implicitly, it is calculated based on the number of analysis bins and the sampling rate - the bins are divided into equal numbers of hz starting with 0 and going up to nyquist. And the frequency data is a convention shared between analysis and resynthesis - the frequencies represented by the bins are determined solely by the number of bins and the sampling rate, and have nothing to do with the input sound.
>>>>>
>>>> To look at it differently one could say that the bins show the
>>>> relative energy of the sound within the frequency continuum. Each bin
>>>> acts as a filter and has a narrow frequency width, it can by
>>>> definition only analyse the energy within that band. It is by putting
>>>> together the bins that we get a meaningful global picture. Moreover
>>>> the resolution of the FFT analysis - i.e. the width of each band - is
>>>> dependent on the FFT size. The smaller the size the more generalised
>>>> the analytical function of the individual bins (but the less
>>>> generalised the time resolution). Of course one bin does not
>>>> necessarily correspond with one partial (however, it can on rare
>>>> occasions), I was never under this allusion. But then not every sound
>>>> can be successfully broken into individual partials as such. In the
>>>> real world I think of sine tones as band-limited noise rather than
>>>> 'pure' frequency component. my personal experiments have demonstrated
>>>> to me that partial analysis/synthesis can only really work with
>>>> harmonic or simpler inharmonic sound sources, hence the need for the
>>>> residual part in the ATS analysis, which doesn't really give a
>>>> convincing result if you ask me.
>>>>
>>>> Best,
>>>>
>>>> Peiman
>>>>
>>>>
>>>>> If you were to encode a pure sine wave doing a slow upward glissando into fft data, the bins would show clusters of active frequencies that would move higher over time and would always be centered on the actual input pitch. The number of bins with significant content would change - spreading wider to encompass more bins as the frequency is between bins, narrowing as the frequency approaches the exact frequency of a bin. If the frequency and phase line up perfectly you may actually get a lucky moment where only one bin has significant data.
>>>>>
>>>>> If you were to decide that since it is only a single sine wave you can recreate it with a single bin, just picking the loudest bin at any moment, you would get a sound that jumps from one harmonic of the frequency step of the analysis to another, with no smooth sliding going on at all. And the amplitude would be very erratic, jumping higher as you approach a harmonic of your analysis' frequency step, and shrinking much lower when between them.
>>>>>
>>>>> Justin Glenn Smith wrote:
>>>>>> If you have an analysis size of 512, and sr of 44100, you have the following frequencies stored:
>>>>>> 0
>>>>>> 43.06640625
>>>>>> all of the harmonics of 43.06640625 hz that are below nyquist
>>>>>>
>>>>>> Nothing else, whatsoever.
>>>>>>
>>>>>> Frequencies that are not in that list are recreated during synthesis but not directly stored. They are generated by cancellations based on phase relationships between frequencies in that list. When you drop a large enough number of bins, 43.06640625 hz and its harmonics will dominate the result more and more.
>>>>>>
>>>>>> With transposition during resynthesis you are changing the phase cancellations evenly with the original pitches. Therefore your original spectrum comes through, in shifted form - the spectrum is shifted, but no spectral information is lost, you don't get arbitrary spectral distortion.
>>>>>>
>>>>>> I call the change that happens with dropping bins a distortion because it is doing something you likely don't want - not just filtering out part of the frequency content, but doing arbitrary frequency shifts, the nature of which are determined by the number of analysis bins and the sampling rate. I think that this can be mitigated by grabbing groups of adjacent frequencies around the biggest spectral peaks, rather than just grabbing the biggest peaks. Perhaps using an envelope, where the amplitude is decreased as one gets further from the peak in the spectrum would be helpful as well, but this is just a hypothesis, I haven't tried it.
>>>>>>
>>>>>> peiman khosravi wrote:
>>>>>>> Yes I read your emails a couple of times after sending that!
>>>>>>>
>>>>>>> I'm glad 2 and 3 give the same result! I am not sure if distortion is
>>>>>>> the right word here. Alterations for sure, but then you expect such
>>>>>>> alterations otherwise what's the point of processing.
>>>>>>>
>>>>>>> What do you mean by distortion exactly? Naturally if we kill a couple
>>>>>>> of bins we will not have the same sound as the original input signal.
>>>>>>> What I was referring to is that sort of blurring effect (loosing the
>>>>>>> transients) you get if you start messing with the frequency data of
>>>>>>> the bins. The bins do actually posses a frequency data right? This
>>>>>>> does not happen if you do not touch the frequency data (in my limited
>>>>>>> experience).
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Peiman
>>>>>>>
>>>>>>> On 17 January 2011 01:17, Justin Glenn Smith  wrote:
>>>>>>>> But you don't sound like you get my point! I haven't been talking about changing the frequency data here at all, except as being on of the few ways you can manipulate the data before resynthesis *without* phase distortions - (this being the case if and only if all bins are transposed by exactly the same amount).
>>>>>>>>
>>>>>>>> 2 and 3 get you the same signal
>>>>>>>>
>>>>>>>> But listening to 1 before the mixing to produce 3 gives a different signal, where distortions will be present.
>>>>>>>>
>>>>>>>> The distortions will also be present if you apply any amount of delay to either of the split signals before mixing to mono.
>>>>>>>>
>>>>>>>> peiman khosravi wrote:
>>>>>>>>> Yes I get your point. I know that changing the frequency data of the
>>>>>>>>> FFT signal, which is not the same as the pure frequency data in your
>>>>>>>>> input signal (i.e. the partials) is a bad idea. My question was, would
>>>>>>>>> changing the amplitude values give you a distorted output?
>>>>>>>>>
>>>>>>>>> Let me rephrase it.
>>>>>>>>>
>>>>>>>>> 1- Say I have two audio channels. I now split my FFT bins into two
>>>>>>>>> groups, sending half the bins (amplitude and frequency pairs) to the
>>>>>>>>> first and the other half to the second channel.
>>>>>>>>> 2- I also make a version in which all the bins go into the same channel
>>>>>>>>> 3- now mix the two channels in the first version into a mono signal.
>>>>>>>>>
>>>>>>>>> The question is are you getting the same result in experiments #2 and 3?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Peiman
>>>>>>>>>
>>>>>>>>> On 17 January 2011 00:32, Justin Glenn Smith  wrote:
>>>>>>>>>> Trying a little harder to get this explanation clear, since it is such a common misunderstanding we are dealing with here:
>>>>>>>>>>
>>>>>>>>>> fft based analysis / resynthesis does not get you "the frequencies" of the original sound
>>>>>>>>>>
>>>>>>>>>> it gives you *one* of a provably infinite number of ways of splitting the input sound into frequencies, all of which will recreate the input sound equally well
>>>>>>>>>>
>>>>>>>>>> manipulating frequencies from fft analysis independently of one another is analogous to scrambling a jigsaw puzzle's pieces - the way the pieces were cut has nothing to do with the original image, but it takes quite a bit of care and/or subtlety to make sure the method of cutting is not the main thing you notice about the resulting rearrangement
>>>>>>>>>>
>>>>>>>>>> Justin Glenn Smith wrote:
>>>>>>>>>>> Csound is turing complete, it could be done in an instrument or UDO in pure csound also, depending on your confidence with writing a sorting algorithm from scratch in a language designed for audio synthesis.
>>>>>>>>>>>
>>>>>>>>>>> A better option would be to make an opcode, my starting point would be to make an array of nbinsx3, where each triplet would contain [amplitude, bin number, phase], then create an array of zeroes with the nbins*2 arity, and sort the input array by amplitude, and finally copy the amp and phase data from the first N bins of the sorted array to the appropriate place based on your stored bin numbers.
>>>>>>>>>>>
>>>>>>>>>>> Mind you, as I mentioned elsewhere in the discussion just now, there will be a strong distortion effect where you will lose frequency content that is not at one of your fixed analysis bin frequencies (pvs does not have dynamic pitch, it simplifies the data into evenly distributed frequency bins, and normally that distortion is negated by the exact opposite distortion in resynthesis - with missing frequency bins you will get a strong artifically induced frequency content, likely to most prominently be present near the harmonics of the spacing of the bins (this will be dependent on your number of bins and your sampling rate and maybe even the overlap?).
>>>>>>>>>>>
>>>>>>>>>>> Aaron Krister Johnson wrote:
>>>>>>>>>>>> So, there are no existing opcodes or tools for this, I take it...one would
>>>>>>>>>>>> have to write a script in the language of one's choosing based on output
>>>>>>>>>>>> from pvlook?
>>>>>>>>>>>>
>>>>>>>>>>>> AKJ
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Jan 16, 2011 at 5:53 PM, Victor Lazzarini
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> My thought on this is that it is possible, but it might be expensive. You
>>>>>>>>>>>>> will need to sort all bins by amp, until the number of requested bins is
>>>>>>>>>>>>> reached.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 16 Jan 2011, at 23:16, Aaron Krister Johnson wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  4) is there a way to tell csound to pick, say, the 13 loudest bins
>>>>>>>>>>>>>> only...it seems like you have to tell it which bins you want, but what if
>>>>>>>>>>>>>> you don't know in advance, or want to make the decision based on loudness,
>>>>>>>>>>>>>> info it should already have, in effect?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>>>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>>>>>>>>>> csound"
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>
>>>>>>>>
>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>
>>>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Aaaron,

Sorry for the delay. I haven't had time to make a stereo version. Not
sure how usefull it will be but I'll post a csd later today when I
have time.

Best,

Peiman

On 16 January 2011 23:16, Aaron Krister Johnson  wrote:
> Peiman,
>
> This sounds very interesting...can you post some stereo demonstrations, or
> is that moot? :)
>
> While we are on the subject of PVS, some related questions:
>
> 1) what is the status of the Loris opcodes? does anyone use them at all in
> their work?
> 2) does anyone use the LP opcodes? They seem broken anyway...maybe they
> should be dropped from the code base?
> 3) Is there a way to get human readable data from a PVS analysis, summary
> data that is, for instance--the perceived pitch of this teapot clang is
> 325.756 hz for most of the signal...or is that too subjective a reality?
> 4) is there a way to tell csound to pick, say, the 13 loudest bins only...it
> seems like you have to tell it which bins you want, but what if you don't
> know in advance, or want to make the decision based on loudness, info it
> should already have, in effect?
>
> Also, I should mention that the csounds.com page needs updating. If anyone
> wants to make me an admin, I'd be happy to slowly chip away at updates. For
> instance, the link to the nabble archive is broken.
>
> Thanks!
>
> AKJ
>
> On Sun, Jan 16, 2011 at 1:21 PM, peiman khosravi 
> wrote:
>>
>> Dear all,
>>
>> I've spend the last 2 hours experimenting with a PVS based UDO that
>> takes the fft bins and randomly distributes each bin to one of six
>> speakers upon each fft window pass. After this I pass the pvs signal
>> through pvsoomth to make the scattering of bins more diffused. The
>> result?? Pure joy! Importantly the individual speakers are not really
>> noticed even if you sit right next to them, the material is truly
>> diffused in the listening space. The speakers just sort of become
>> invisible! I would like to make different versions of this with more
>> controls and so on.
>>
>> Has anyone experimented with similar things?? I'd be very interested
>> to hear about your experiences.
>>
>> Best,
>>
>> Peiman
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 17.01.2011, at 01:53, peiman khosravi wrote:

> Yes I get your point. I know that changing the frequency data of the
> FFT signal, which is not the same as the pure frequency data in your
> input signal (i.e. the partials) is a bad idea. My question was, would
> changing the amplitude values give you a distorted output?
> 
> Let me rephrase it.
> 
> 1- Say I have two audio channels. I now split my FFT bins into two
> groups, sending half the bins (amplitude and frequency pairs) to the
> first and the other half to the second channel.
> 2- I also make a version in which all the bins go into the same channel
> 3- now mix the two channels in the first version into a mono signal.
> 
> The question is are you getting the same result in experiments #2 and 3?

here is a late reply - sorry, i'm just an occasional lurker on this list.
as justin said, yes, 2 and 3 will sound the same. but only if version 3 is summed into a mono signal, as you say.

my impression was, that you wanted to spectrally diffuse the signal into a number of different channels.
that would mean, you are separating the data from the two channels above spatially by playing it back on different speakers.
in this case you _do_ change the phase (frequency) data of the bins, which will result in typical artefacts, especially if you separate the data of neighbouring bins, that together form a single partial.

i've tried this kind of spectral diffusion before (although not in csound) and found the results nevertheless to be interesting.

volker.







Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Volker,

I find that the discrete panning of the FFT bins can give quite good
results with already grainy textures and it works well enough with
sustain sounds when you add pvsmooth to the result (but this naturally
changes the morphology of the sound).

I'm working on a csd to do a continuous panning of the bins so that
the adjacent bins are not drastically separated. I shall report back
the result.

Best,

Peiman

On 21 January 2011 17:46, volker böhm  wrote:
>
>
> On 17.01.2011, at 01:53, peiman khosravi wrote:
>
>> Yes I get your point. I know that changing the frequency data of the
>> FFT signal, which is not the same as the pure frequency data in your
>> input signal (i.e. the partials) is a bad idea. My question was, would
>> changing the amplitude values give you a distorted output?
>>
>> Let me rephrase it.
>>
>> 1- Say I have two audio channels. I now split my FFT bins into two
>> groups, sending half the bins (amplitude and frequency pairs) to the
>> first and the other half to the second channel.
>> 2- I also make a version in which all the bins go into the same channel
>> 3- now mix the two channels in the first version into a mono signal.
>>
>> The question is are you getting the same result in experiments #2 and 3?
>
> here is a late reply - sorry, i'm just an occasional lurker on this list.
> as justin said, yes, 2 and 3 will sound the same. but only if version 3 is summed into a mono signal, as you say.
>
> my impression was, that you wanted to spectrally diffuse the signal into a number of different channels.
> that would mean, you are separating the data from the two channels above spatially by playing it back on different speakers.
> in this case you _do_ change the phase (frequency) data of the bins, which will result in typical artefacts, especially if you separate the data of neighbouring bins, that together form a single partial.
>
> i've tried this kind of spectral diffusion before (although not in csound) and found the results nevertheless to be interesting.
>
> volker.
>
>
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Just a broad technical point about pvoc (and FFT) bin "hacking": it is 
important to understand that in the vast majority of cases this is far 
from "correct" in terms of the dsp (maths). If you for example zero a 
bunch of bins in the thought of using it as a brick-wall filter, you 
will get significant temporal aliasing, as a "vertical" cutoff 
translates to an infinitely long impulse response (e.g. ringing). (I 
write this fully in the knowledge I did exactly this in my original 
documentation example for "pvsmaska"). Musicians have a standard and 
entirely respectable answer to this - if it is useful as a sound, it is 
useful even if it contravenes the dsp "laws of physics". The repertoire 
is full of sounds that are really dsp "gone wrong" but which sound cool.

So whether this counts as "distortion" is a matter of taste and 
judgement; but one way or another there will be inevitable sonic 
consequences to any hacking of this kind - panning bins between speakers 
implies (per channel) a similar form of dsp rule-breaking, if bins are 
simply turned on or off.  Even a simple linear slope between on and off, 
over a few bins, would mitigate the more egregious dsp issues while 
still, hopefully, ticking the "cool:" box.

Richard Dobson

On 22/01/2011 11:43, peiman khosravi wrote:
> Hi Volker,
>
> I find that the discrete panning of the FFT bins can give quite good
> results with already grainy textures and it works well enough with
> sustain sounds when you add pvsmooth to the result (but this naturally
> changes the morphology of the sound).
>
> I'm working on a csd to do a continuous panning of the bins so that
> the adjacent bins are not drastically separated. I shall report back
> the result.
>
> Best,
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I wonder how the representation that is used in the pvoc affects these
problems,
since the calculation of instantaneous frequency is performed already,
I realise that you can't change frequencies to beyond the boundaries of
their bin's range, but in modifying these frequencies and amplitudes, they
will then be converted into a form which can be used by the ifft, so are some
of the problems with phase reduced compared with using the fft directly.
Also, will using an oscillator bank synthesis avoid this amplitude problem,
I'm not sure I understand this, do you mean that if you set the amplitude for
one bin to 0, then this bin will still contribute to the result.
Might partial tracking help, I notice the tracks opcodes do this, so there
is some further layer of abstraction from the fft.This could also serve to
avoid problems where a partial appears to be clustered ove a number of bins.

- Joel

On 22 January 2011 13:40, Richard Dobson  wrote:
> Just a broad technical point about pvoc (and FFT) bin "hacking": it is
> important to understand that in the vast majority of cases this is far from
> "correct" in terms of the dsp (maths). If you for example zero a bunch of
> bins in the thought of using it as a brick-wall filter, you will get
> significant temporal aliasing, as a "vertical" cutoff translates to an
> infinitely long impulse response (e.g. ringing). (I write this fully in the
> knowledge I did exactly this in my original documentation example for
> "pvsmaska"). Musicians have a standard and entirely respectable answer to
> this - if it is useful as a sound, it is useful even if it contravenes the
> dsp "laws of physics". The repertoire is full of sounds that are really dsp
> "gone wrong" but which sound cool.
>
> So whether this counts as "distortion" is a matter of taste and judgement;
> but one way or another there will be inevitable sonic consequences to any
> hacking of this kind - panning bins between speakers implies (per channel) a
> similar form of dsp rule-breaking, if bins are simply turned on or off.
>  Even a simple linear slope between on and off, over a few bins, would
> mitigate the more egregious dsp issues while still, hopefully, ticking the
> "cool:" box.
>
> Richard Dobson
>
> On 22/01/2011 11:43, peiman khosravi wrote:
>>
>> Hi Volker,
>>
>> I find that the discrete panning of the FFT bins can give quite good
>> results with already grainy textures and it works well enough with
>> sustain sounds when you add pvsmooth to the result (but this naturally
>> changes the morphology of the sound).
>>
>> I'm working on a csd to do a continuous panning of the bins so that
>> the adjacent bins are not drastically separated. I shall report back
>> the result.
>>
>> Best,
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks Richard. So the slope will mitigate rather than eliminate the
artifacts? Does this mean that frequency filtering of any kind based
on FFT analysis is never going to be mathematically 100% correct or is
there a way to do it right (other than partial tracking)?

Thanks

Peiman

On 22 January 2011 12:40, Richard Dobson  wrote:
> Just a broad technical point about pvoc (and FFT) bin "hacking": it is
> important to understand that in the vast majority of cases this is far from
> "correct" in terms of the dsp (maths). If you for example zero a bunch of
> bins in the thought of using it as a brick-wall filter, you will get
> significant temporal aliasing, as a "vertical" cutoff translates to an
> infinitely long impulse response (e.g. ringing). (I write this fully in the
> knowledge I did exactly this in my original documentation example for
> "pvsmaska"). Musicians have a standard and entirely respectable answer to
> this - if it is useful as a sound, it is useful even if it contravenes the
> dsp "laws of physics". The repertoire is full of sounds that are really dsp
> "gone wrong" but which sound cool.
>
> So whether this counts as "distortion" is a matter of taste and judgement;
> but one way or another there will be inevitable sonic consequences to any
> hacking of this kind - panning bins between speakers implies (per channel) a
> similar form of dsp rule-breaking, if bins are simply turned on or off.
>  Even a simple linear slope between on and off, over a few bins, would
> mitigate the more egregious dsp issues while still, hopefully, ticking the
> "cool:" box.
>
> Richard Dobson
>
> On 22/01/2011 11:43, peiman khosravi wrote:
>>
>> Hi Volker,
>>
>> I find that the discrete panning of the FFT bins can give quite good
>> results with already grainy textures and it works well enough with
>> sustain sounds when you add pvsmooth to the result (but this naturally
>> changes the morphology of the sound).
>>
>> I'm working on a csd to do a continuous panning of the bins so that
>> the adjacent bins are not drastically separated. I shall report back
>> the result.
>>
>> Best,
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

No, if you apply a filter that is the spectral version of the time- 
domain, you'll get the correct
result (in the case of PV, except for the phase response). For  
instance, if you use the magnitude
response of a resonator, you will get the filtering as expected.

What Richard is saying is that a brick-wall filter will have time  
issues, but that is just as true if the
filter were implemented in the usual way with delays etc in the time- 
domain.

Victor

On 22 Jan 2011, at 14:38, peiman khosravi wrote:

> Thanks Richard. So the slope will mitigate rather than eliminate the
> artifacts? Does this mean that frequency filtering of any kind based
> on FFT analysis is never going to be mathematically 100% correct or is
> there a way to do it right (other than partial tracking)?
>
> Thanks
>
> Peiman
>
> On 22 January 2011 12:40, Richard Dobson  > wrote:
>> Just a broad technical point about pvoc (and FFT) bin "hacking": it  
>> is
>> important to understand that in the vast majority of cases this is  
>> far from
>> "correct" in terms of the dsp (maths). If you for example zero a  
>> bunch of
>> bins in the thought of using it as a brick-wall filter, you will get
>> significant temporal aliasing, as a "vertical" cutoff translates to  
>> an
>> infinitely long impulse response (e.g. ringing). (I write this  
>> fully in the
>> knowledge I did exactly this in my original documentation example for
>> "pvsmaska"). Musicians have a standard and entirely respectable  
>> answer to
>> this - if it is useful as a sound, it is useful even if it  
>> contravenes the
>> dsp "laws of physics". The repertoire is full of sounds that are  
>> really dsp
>> "gone wrong" but which sound cool.
>>
>> So whether this counts as "distortion" is a matter of taste and  
>> judgement;
>> but one way or another there will be inevitable sonic consequences  
>> to any
>> hacking of this kind - panning bins between speakers implies (per  
>> channel) a
>> similar form of dsp rule-breaking, if bins are simply turned on or  
>> off.
>>  Even a simple linear slope between on and off, over a few bins,  
>> would
>> mitigate the more egregious dsp issues while still, hopefully,  
>> ticking the
>> "cool:" box.
>>
>> Richard Dobson
>>
>> On 22/01/2011 11:43, peiman khosravi wrote:
>>>
>>> Hi Volker,
>>>
>>> I find that the discrete panning of the FFT bins can give quite good
>>> results with already grainy textures and it works well enough with
>>> sustain sounds when you add pvsmooth to the result (but this  
>>> naturally
>>> changes the morphology of the sound).
>>>
>>> I'm working on a csd to do a continuous panning of the bins so that
>>> the adjacent bins are not drastically separated. I shall report back
>>> the result.
>>>
>>> Best,
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 22/01/2011 13:31, Joel Ross wrote:
> I wonder how the representation that is used in the pvoc affects these
> problems,
> since the calculation of instantaneous frequency is performed already,
> I realise that you can't change frequencies to beyond the boundaries of
> their bin's range, but in modifying these frequencies and amplitudes, they
> will then be converted into a form which can be used by the ifft, so are some
> of the problems with phase reduced compared with using the fft directly.
> Also, will using an oscillator bank synthesis avoid this amplitude problem,
> I'm not sure I understand this, do you mean that if you set the amplitude for
> one bin to 0, then this bin will still contribute to the result.
> Might partial tracking help, I notice the tracks opcodes do this, so there
> is some further layer of abstraction from the fft.This could also serve to
> avoid problems where a partial appears to be clustered ove a number of bins.
>
>


All good questions. I was writing specifically about amplitude issues, 
rather than frequency ones; each has their own issues. The oscillator 
bank solution is often cited as to be preferred after bin frequency 
modifications - as it avoids the sometimes tricky issue of what bin a 
modified frequency should go in. That is to say, you ~can~ change a 
frequency beyond the rage of a bin - you just then have to assign it to 
a new bin appropriate to it. With respect to that filter bank - ~in 
principle~ if you resynthesize all bins, it should be identical to 
applying the inverse pvoc/fft process (the fft is simply faster). 
Cutting out bins will have  consequences for phase not unrelated to 
those when moving frequencies around - phases get more or less jumbled 
up, and (conflated with the use of overlapping windows which carries its 
own implications for phase handling) can result in some surprising echo 
and reverb-like effects.

In pvoc (using windowing) multiple bins combine to represent a single 
source partial; if you remove some of them, certainly the net amplitude 
will change (in either direction). The sun of sines of the same 
frequency always makes a new sine of the same frequency (but possibly of 
a different amplitude). For a source partial adjacent bins have 
frequencies that are typically very close, but ~not exactly~ the same 
(maybe to a few decimal places); i.e. small but non-zero differences. If 
these differences are expanded via simple multiplication in the process 
of pitch scaling, the result is frequency smearing - what was one source 
partial has spread out to become several close components. This also 
means that such thngs as transients become spread out in time (a clap 
becomes a splash), arguably a form of temporal aliasing.

I have never looked closely enough at the maths to quote it, but in 
principle removing some bins from a group representing one partial may 
result in a (admittedly small) frequency change to that partial. It is 
related to the phenomenon of beats - two very close frequencies will 
beat generating periodic amplitiude changes (casually aka vibrato). The 
amplitude change is what we notice, but really there are two frequencies 
there.  In the inverse case,  analysing a sinusoid to which some 
amplitude modulation has been applied will result in not one single bin, 
but two (or more) - each process is the inverse of the other. It is akin 
to ring modulation with a very low frequency. So, if I have not got the 
theory hopelessly wrong (which is ~very~ possible!), "in theory" zeroing 
bins will have effects (depending on the numbers in each case, etc) not 
only on amplitude (the most noticeable) but frequency too.

In the original CARL pvoc, one standard option was to synthesis odd and 
even bins separately, to obtain a quasi-stereo effect from a mono 
source. The mere fact that this works as well as it does speaks volumes 
for the general robustness of pvoc generally. But given the use of a 
window such as Hann or Kaiser, etc, in principle a zero-value bin is not 
kosher, because either the data suffers spectral smearing anyway by 
being inharmonic (so all bins have nonzero values) or the signal was 
exactly aligned (which for a sinusoid would produce a single non-zero 
amplitude bin); in the latter case the use of the window introduces 
slight smearing that again makes at least adjacent bins significantsly 
non-zero and other bins very small but non-zero). So ostensibly a "truly 
zero" bin can never arise as a result of fft/pvoc analysis. But in any 
system of finite word-length, some values may effectively become zero - 
that is a separate consideration. If pvoc sounds better in doubles than 
in singles, that would be one of the reasons. As to how much of an 
effect such manipulations have, "it all depends"; and I am unfamiliar 
with literature that analyses it down to that level of detail. Most of 
the attention has been devoted to the familair issues in pitch shifting, 
as that is where most of the difficulty lies.


Of course, where you actually want spectral diffusion, just about any 
bin hacking will give it to you!

Richard Dobson




Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 22/01/2011 14:55, Victor Lazzarini wrote:
> No, if you apply a filter that is the spectral version of the
> time-domain, you'll get the correct
> result (in the case of PV, except for the phase response). For instance,
> if you use the magnitude
> response of a resonator, you will get the filtering as expected.
>
> What Richard is saying is that a brick-wall filter will have time
> issues, but that is just as true if the
> filter were implemented in the usual way with delays etc in the
> time-domain.
>


And as a further follow-up - in applying a filter in this way you are 
doing multiplication in the frequency domain, which corresponds to 
convolution in the time domain - and convolution is of course a way to 
apply reverb to a sound (indeed using the FFT for speed) - a very vivid 
example of how the two domains relate to one another. The key trick in 
fft convolution is to use an FFT size twice the length of the convolvand 
(reverb IR), aka "zero padding", so that the results of the convolution 
are properly linear (that impulse response again). Without that extra 
space, you get temporal aliasing (all the impulse response gets folded 
back into the original-length  frame).

Richard Dobson



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi,

Very interesting discussion...

In my experience, the effect can work well for
noisy/concrete/electroacoustic sounds, especially those which are
irregular and which don't have something resembling a harmonic
spectrum. In these cases, the image will break up, and you will hear
distinct parts of the sound coming from different areas. If you try to
do it with a cello, you will find that the brain will identify all
partials spread throughout space as belonging to the same source or
"stream" and will group them together in the most plausible location
(possibly according to where the attack transients are mostly coming
from), so the effect will actually not be very impressive...

Cheers,
Andres

On Sat, Jan 22, 2011 at 11:43 AM, peiman khosravi
 wrote:
> Hi Volker,
>
> I find that the discrete panning of the FFT bins can give quite good
> results with already grainy textures and it works well enough with
> sustain sounds when you add pvsmooth to the result (but this naturally
> changes the morphology of the sound).
>
> I'm working on a csd to do a continuous panning of the bins so that
> the adjacent bins are not drastically separated. I shall report back
> the result.
>
> Best,
>
> Peiman
>
> On 21 January 2011 17:46, volker böhm  wrote:
>>
>>
>> On 17.01.2011, at 01:53, peiman khosravi wrote:
>>
>>> Yes I get your point. I know that changing the frequency data of the
>>> FFT signal, which is not the same as the pure frequency data in your
>>> input signal (i.e. the partials) is a bad idea. My question was, would
>>> changing the amplitude values give you a distorted output?
>>>
>>> Let me rephrase it.
>>>
>>> 1- Say I have two audio channels. I now split my FFT bins into two
>>> groups, sending half the bins (amplitude and frequency pairs) to the
>>> first and the other half to the second channel.
>>> 2- I also make a version in which all the bins go into the same channel
>>> 3- now mix the two channels in the first version into a mono signal.
>>>
>>> The question is are you getting the same result in experiments #2 and 3?
>>
>> here is a late reply - sorry, i'm just an occasional lurker on this list.
>> as justin said, yes, 2 and 3 will sound the same. but only if version 3 is summed into a mono signal, as you say.
>>
>> my impression was, that you wanted to spectrally diffuse the signal into a number of different channels.
>> that would mean, you are separating the data from the two channels above spatially by playing it back on different speakers.
>> in this case you _do_ change the phase (frequency) data of the bins, which will result in typical artefacts, especially if you separate the data of neighbouring bins, that together form a single partial.
>>
>> i've tried this kind of spectral diffusion before (although not in csound) and found the results nevertheless to be interesting.
>>
>> volker.
>>
>>
>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks Richard,

I have read your and Victor's posts several times and I think I just
about understand them.

Best,

Peiman

On 22 January 2011 16:16, Richard Dobson  wrote:
> On 22/01/2011 14:55, Victor Lazzarini wrote:
>>
>> No, if you apply a filter that is the spectral version of the
>> time-domain, you'll get the correct
>> result (in the case of PV, except for the phase response). For instance,
>> if you use the magnitude
>> response of a resonator, you will get the filtering as expected.
>>
>> What Richard is saying is that a brick-wall filter will have time
>> issues, but that is just as true if the
>> filter were implemented in the usual way with delays etc in the
>> time-domain.
>>
>
>
> And as a further follow-up - in applying a filter in this way you are doing
> multiplication in the frequency domain, which corresponds to convolution in
> the time domain - and convolution is of course a way to apply reverb to a
> sound (indeed using the FFT for speed) - a very vivid example of how the two
> domains relate to one another. The key trick in fft convolution is to use an
> FFT size twice the length of the convolvand (reverb IR), aka "zero padding",
> so that the results of the convolution are properly linear (that impulse
> response again). Without that extra space, you get temporal aliasing (all
> the impulse response gets folded back into the original-length  frame).
>
> Richard Dobson
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks Victor,

Please feel free to ignore this question if it is too stupid or time
consuming. I would love to know what would be the spectral version of
a time-domain filter. I assume that it is purely mathematical and has
no direct connection with the percieved filter parameters?

best,

Peiman

On 22 January 2011 15:55, Victor Lazzarini  wrote:
> No, if you apply a filter that is the spectral version of the time-domain,
> you'll get the correct
> result (in the case of PV, except for the phase response). For instance, if
> you use the magnitude
> response of a resonator, you will get the filtering as expected.
>
> What Richard is saying is that a brick-wall filter will have time issues,
> but that is just as true if the
> filter were implemented in the usual way with delays etc in the time-domain.
>
> Victor
>
> On 22 Jan 2011, at 14:38, peiman khosravi wrote:
>
>> Thanks Richard. So the slope will mitigate rather than eliminate the
>> artifacts? Does this mean that frequency filtering of any kind based
>> on FFT analysis is never going to be mathematically 100% correct or is
>> there a way to do it right (other than partial tracking)?
>>
>> Thanks
>>
>> Peiman
>>
>> On 22 January 2011 12:40, Richard Dobson 
>> wrote:
>>>
>>> Just a broad technical point about pvoc (and FFT) bin "hacking": it is
>>> important to understand that in the vast majority of cases this is far
>>> from
>>> "correct" in terms of the dsp (maths). If you for example zero a bunch of
>>> bins in the thought of using it as a brick-wall filter, you will get
>>> significant temporal aliasing, as a "vertical" cutoff translates to an
>>> infinitely long impulse response (e.g. ringing). (I write this fully in
>>> the
>>> knowledge I did exactly this in my original documentation example for
>>> "pvsmaska"). Musicians have a standard and entirely respectable answer to
>>> this - if it is useful as a sound, it is useful even if it contravenes
>>> the
>>> dsp "laws of physics". The repertoire is full of sounds that are really
>>> dsp
>>> "gone wrong" but which sound cool.
>>>
>>> So whether this counts as "distortion" is a matter of taste and
>>> judgement;
>>> but one way or another there will be inevitable sonic consequences to any
>>> hacking of this kind - panning bins between speakers implies (per
>>> channel) a
>>> similar form of dsp rule-breaking, if bins are simply turned on or off.
>>>  Even a simple linear slope between on and off, over a few bins, would
>>> mitigate the more egregious dsp issues while still, hopefully, ticking
>>> the
>>> "cool:" box.
>>>
>>> Richard Dobson
>>>
>>> On 22/01/2011 11:43, peiman khosravi wrote:
>>>>
>>>> Hi Volker,
>>>>
>>>> I find that the discrete panning of the FFT bins can give quite good
>>>> results with already grainy textures and it works well enough with
>>>> sustain sounds when you add pvsmooth to the result (but this naturally
>>>> changes the morphology of the sound).
>>>>
>>>> I'm working on a csd to do a continuous panning of the bins so that
>>>> the adjacent bins are not drastically separated. I shall report back
>>>> the result.
>>>>
>>>> Best,
>>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

It's simple actually. There are two ways to see this. The first is if  
you take the
DFT of the impulse response of a filter, you will get its 'spectral  
version'.  The magnitudes
of the DFT make up the amplitude response (how the filter changes the  
input amplitudes)
and the phases are the phase response (the various delays at different  
frequencies).

The other way is this: if you know the filter amplitude and phase  
response (together they make the frequency response) as an analytical
expression (say from its Z-transform), you can sample it at the  
different DFT frequencies and you have
its 'spectral version'.

Victor


On 23 Jan 2011, at 12:21, peiman khosravi wrote:

> Thanks Victor,
>
> Please feel free to ignore this question if it is too stupid or time
> consuming. I would love to know what would be the spectral version of
> a time-domain filter. I assume that it is purely mathematical and has
> no direct connection with the percieved filter parameters?
>
> best,
>
> Peiman
>
> On 22 January 2011 15:55, Victor Lazzarini  
>  wrote:
>> No, if you apply a filter that is the spectral version of the time- 
>> domain,
>> you'll get the correct
>> result (in the case of PV, except for the phase response). For  
>> instance, if
>> you use the magnitude
>> response of a resonator, you will get the filtering as expected.
>>
>> What Richard is saying is that a brick-wall filter will have time  
>> issues,
>> but that is just as true if the
>> filter were implemented in the usual way with delays etc in the  
>> time-domain.
>>
>> Victor
>>
>> On 22 Jan 2011, at 14:38, peiman khosravi wrote:
>>
>>> Thanks Richard. So the slope will mitigate rather than eliminate the
>>> artifacts? Does this mean that frequency filtering of any kind based
>>> on FFT analysis is never going to be mathematically 100% correct  
>>> or is
>>> there a way to do it right (other than partial tracking)?
>>>
>>> Thanks
>>>
>>> Peiman
>>>
>>> On 22 January 2011 12:40, Richard Dobson >> >
>>> wrote:
>>>>
>>>> Just a broad technical point about pvoc (and FFT) bin "hacking":  
>>>> it is
>>>> important to understand that in the vast majority of cases this  
>>>> is far
>>>> from
>>>> "correct" in terms of the dsp (maths). If you for example zero a  
>>>> bunch of
>>>> bins in the thought of using it as a brick-wall filter, you will  
>>>> get
>>>> significant temporal aliasing, as a "vertical" cutoff translates  
>>>> to an
>>>> infinitely long impulse response (e.g. ringing). (I write this  
>>>> fully in
>>>> the
>>>> knowledge I did exactly this in my original documentation example  
>>>> for
>>>> "pvsmaska"). Musicians have a standard and entirely respectable  
>>>> answer to
>>>> this - if it is useful as a sound, it is useful even if it  
>>>> contravenes
>>>> the
>>>> dsp "laws of physics". The repertoire is full of sounds that are  
>>>> really
>>>> dsp
>>>> "gone wrong" but which sound cool.
>>>>
>>>> So whether this counts as "distortion" is a matter of taste and
>>>> judgement;
>>>> but one way or another there will be inevitable sonic  
>>>> consequences to any
>>>> hacking of this kind - panning bins between speakers implies (per
>>>> channel) a
>>>> similar form of dsp rule-breaking, if bins are simply turned on  
>>>> or off.
>>>>  Even a simple linear slope between on and off, over a few bins,  
>>>> would
>>>> mitigate the more egregious dsp issues while still, hopefully,  
>>>> ticking
>>>> the
>>>> "cool:" box.
>>>>
>>>> Richard Dobson
>>>>
>>>> On 22/01/2011 11:43, peiman khosravi wrote:
>>>>>
>>>>> Hi Volker,
>>>>>
>>>>> I find that the discrete panning of the FFT bins can give quite  
>>>>> good
>>>>> results with already grainy textures and it works well enough with
>>>>> sustain sounds when you add pvsmooth to the result (but this  
>>>>> naturally
>>>>> changes the morphology of the sound).
>>>>>
>>>>> I'm working on a csd to do a continuous panning of the bins so  
>>>>> that
>>>>> the adjacent bins are not drastically separated. I shall report  
>>>>> back
>>>>> the result.
>>>>>
>>>>> Best,
>>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>          https://sourceforge.net/tracker/? 
>>>> group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/? 
>>> group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks Victor,

It is all beginning to make sens now.

Here is the first working version of the spectral diffuser for anyone
interested. It works rather well actually! This one requires 6
channels but it would be easy to change the number of channels. CPU
wise not that demanding actually.

Best,

Peiman


On 23 January 2011 15:21, Victor Lazzarini  wrote:
> It's simple actually. There are two ways to see this. The first is if you
> take the
> DFT of the impulse response of a filter, you will get its 'spectral
> version'.  The magnitudes
> of the DFT make up the amplitude response (how the filter changes the input
> amplitudes)
> and the phases are the phase response (the various delays at different
> frequencies).
>
> The other way is this: if you know the filter amplitude and phase response
> (together they make the frequency response) as an analytical
> expression (say from its Z-transform), you can sample it at the different
> DFT frequencies and you have
> its 'spectral version'.
>
> Victor
>
>
> On 23 Jan 2011, at 12:21, peiman khosravi wrote:
>
>> Thanks Victor,
>>
>> Please feel free to ignore this question if it is too stupid or time
>> consuming. I would love to know what would be the spectral version of
>> a time-domain filter. I assume that it is purely mathematical and has
>> no direct connection with the percieved filter parameters?
>>
>> best,
>>
>> Peiman
>>
>> On 22 January 2011 15:55, Victor Lazzarini 
>> wrote:
>>>
>>> No, if you apply a filter that is the spectral version of the
>>> time-domain,
>>> you'll get the correct
>>> result (in the case of PV, except for the phase response). For instance,
>>> if
>>> you use the magnitude
>>> response of a resonator, you will get the filtering as expected.
>>>
>>> What Richard is saying is that a brick-wall filter will have time issues,
>>> but that is just as true if the
>>> filter were implemented in the usual way with delays etc in the
>>> time-domain.
>>>
>>> Victor
>>>
>>> On 22 Jan 2011, at 14:38, peiman khosravi wrote:
>>>
>>>> Thanks Richard. So the slope will mitigate rather than eliminate the
>>>> artifacts? Does this mean that frequency filtering of any kind based
>>>> on FFT analysis is never going to be mathematically 100% correct or is
>>>> there a way to do it right (other than partial tracking)?
>>>>
>>>> Thanks
>>>>
>>>> Peiman
>>>>
>>>> On 22 January 2011 12:40, Richard Dobson
>>>> 
>>>> wrote:
>>>>>
>>>>> Just a broad technical point about pvoc (and FFT) bin "hacking": it is
>>>>> important to understand that in the vast majority of cases this is far
>>>>> from
>>>>> "correct" in terms of the dsp (maths). If you for example zero a bunch
>>>>> of
>>>>> bins in the thought of using it as a brick-wall filter, you will get
>>>>> significant temporal aliasing, as a "vertical" cutoff translates to an
>>>>> infinitely long impulse response (e.g. ringing). (I write this fully in
>>>>> the
>>>>> knowledge I did exactly this in my original documentation example for
>>>>> "pvsmaska"). Musicians have a standard and entirely respectable answer
>>>>> to
>>>>> this - if it is useful as a sound, it is useful even if it contravenes
>>>>> the
>>>>> dsp "laws of physics". The repertoire is full of sounds that are really
>>>>> dsp
>>>>> "gone wrong" but which sound cool.
>>>>>
>>>>> So whether this counts as "distortion" is a matter of taste and
>>>>> judgement;
>>>>> but one way or another there will be inevitable sonic consequences to
>>>>> any
>>>>> hacking of this kind - panning bins between speakers implies (per
>>>>> channel) a
>>>>> similar form of dsp rule-breaking, if bins are simply turned on or off.
>>>>>  Even a simple linear slope between on and off, over a few bins, would
>>>>> mitigate the more egregious dsp issues while still, hopefully, ticking
>>>>> the
>>>>> "cool:" box.
>>>>>
>>>>> Richard Dobson
>>>>>
>>>>> On 22/01/2011 11:43, peiman khosravi wrote:
>>>>>>
>>>>>> Hi Volker,
>>>>>>
>>>>>> I find that the discrete panning of the FFT bins can give quite good
>>>>>> results with already grainy textures and it works well enough with
>>>>>> sustain sounds when you add pvsmooth to the result (but this naturally
>>>>>> changes the morphology of the sound).
>>>>>>
>>>>>> I'm working on a csd to do a continuous panning of the bins so that
>>>>>> the adjacent bins are not drastically separated. I shall report back
>>>>>> the result.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>         https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

If only I had more than two speakers to try it out with :(



On 23 January 2011 18:24, peiman khosravi  wrote:
> Thanks Victor,
>
> It is all beginning to make sens now.
>
> Here is the first working version of the spectral diffuser for anyone
> interested. It works rather well actually! This one requires 6
> channels but it would be easy to change the number of channels. CPU
> wise not that demanding actually.
>
> Best,
>
> Peiman
>
>
> On 23 January 2011 15:21, Victor Lazzarini  wrote:
>> It's simple actually. There are two ways to see this. The first is if you
>> take the
>> DFT of the impulse response of a filter, you will get its 'spectral
>> version'.  The magnitudes
>> of the DFT make up the amplitude response (how the filter changes the input
>> amplitudes)
>> and the phases are the phase response (the various delays at different
>> frequencies).
>>
>> The other way is this: if you know the filter amplitude and phase response
>> (together they make the frequency response) as an analytical
>> expression (say from its Z-transform), you can sample it at the different
>> DFT frequencies and you have
>> its 'spectral version'.
>>
>> Victor
>>
>>
>> On 23 Jan 2011, at 12:21, peiman khosravi wrote:
>>
>>> Thanks Victor,
>>>
>>> Please feel free to ignore this question if it is too stupid or time
>>> consuming. I would love to know what would be the spectral version of
>>> a time-domain filter. I assume that it is purely mathematical and has
>>> no direct connection with the percieved filter parameters?
>>>
>>> best,
>>>
>>> Peiman
>>>
>>> On 22 January 2011 15:55, Victor Lazzarini 
>>> wrote:
>>>>
>>>> No, if you apply a filter that is the spectral version of the
>>>> time-domain,
>>>> you'll get the correct
>>>> result (in the case of PV, except for the phase response). For instance,
>>>> if
>>>> you use the magnitude
>>>> response of a resonator, you will get the filtering as expected.
>>>>
>>>> What Richard is saying is that a brick-wall filter will have time issues,
>>>> but that is just as true if the
>>>> filter were implemented in the usual way with delays etc in the
>>>> time-domain.
>>>>
>>>> Victor
>>>>
>>>> On 22 Jan 2011, at 14:38, peiman khosravi wrote:
>>>>
>>>>> Thanks Richard. So the slope will mitigate rather than eliminate the
>>>>> artifacts? Does this mean that frequency filtering of any kind based
>>>>> on FFT analysis is never going to be mathematically 100% correct or is
>>>>> there a way to do it right (other than partial tracking)?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Peiman
>>>>>
>>>>> On 22 January 2011 12:40, Richard Dobson
>>>>> 
>>>>> wrote:
>>>>>>
>>>>>> Just a broad technical point about pvoc (and FFT) bin "hacking": it is
>>>>>> important to understand that in the vast majority of cases this is far
>>>>>> from
>>>>>> "correct" in terms of the dsp (maths). If you for example zero a bunch
>>>>>> of
>>>>>> bins in the thought of using it as a brick-wall filter, you will get
>>>>>> significant temporal aliasing, as a "vertical" cutoff translates to an
>>>>>> infinitely long impulse response (e.g. ringing). (I write this fully in
>>>>>> the
>>>>>> knowledge I did exactly this in my original documentation example for
>>>>>> "pvsmaska"). Musicians have a standard and entirely respectable answer
>>>>>> to
>>>>>> this - if it is useful as a sound, it is useful even if it contravenes
>>>>>> the
>>>>>> dsp "laws of physics". The repertoire is full of sounds that are really
>>>>>> dsp
>>>>>> "gone wrong" but which sound cool.
>>>>>>
>>>>>> So whether this counts as "distortion" is a matter of taste and
>>>>>> judgement;
>>>>>> but one way or another there will be inevitable sonic consequences to
>>>>>> any
>>>>>> hacking of this kind - panning bins between speakers implies (per
>>>>>> channel) a
>>>>>> similar form of dsp rule-breaking, if bins are simply turned on or off.
>>>>>>  Even a simple linear slope between on and off, over a few bins, would
>>>>>> mitigate the more egregious dsp issues while still, hopefully, ticking
>>>>>> the
>>>>>> "cool:" box.
>>>>>>
>>>>>> Richard Dobson
>>>>>>
>>>>>> On 22/01/2011 11:43, peiman khosravi wrote:
>>>>>>>
>>>>>>> Hi Volker,
>>>>>>>
>>>>>>> I find that the discrete panning of the FFT bins can give quite good
>>>>>>> results with already grainy textures and it works well enough with
>>>>>>> sustain sounds when you add pvsmooth to the result (but this naturally
>>>>>>> changes the morphology of the sound).
>>>>>>>
>>>>>>> I'm working on a csd to do a continuous panning of the bins so that
>>>>>>> the adjacent bins are not drastically separated. I shall report back
>>>>>>> the result.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>         https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"