Hello,

I'm making some sound examples with the pvs opcodes for a sound quality
comparison with the native fft objects in maxmsp (I'v always thought that
csound sounds better but now is time for the real experiment!). 

I've just encountered a subtle but strange artefact with pvshift. Listening
to the audio example I made earlier
http://idisk.mac.com/peimankh/Public/pvstest.aiff you will notice that the
very end part of the file sounds blurry (fft artefact) compared to the
beginning of the file. This is despite the frequency shift being set to +160
for both parts (after a krate change in the middle). So it seems that
changing the shift parameter in krate somehow messes up the timing of the
fft windows and the resynthesis gradually degrades. Maybe I'm doing
something wrong, any insights would be most welcome.

You can see my analysis settings from the instrument bellow...

Many Thanks
Peiman

ain1,ain2	xin
ain1 	butterhp	 ain1, 20 ;remove dc
ain2 	butterhp	 ain2, 20
ftps1  pvsanal   ain1, 4096, 4096/4, 4096*2, 1 ; analyse
ftps2  pvsanal   ain2, 4096, 4096/4, 4096*2, 1

fscale1  pvscale   ftps1, 1.0, 0        ; transpose
fscale2  pvscale   ftps2, 1.0, 0

fshift1 pvshift fscale1, gk_blue_auto0, 0.0, 0
fshift2 pvshift fscale2, gk_blue_auto0, 0.0, 0

aout1  pvsynth  fshift1                      ; synthesise
aout2  pvsynth  fshift2      
                                       
xout	aout1,aout2
   
-- 
View this message in context: http://www.nabble.com/bizarre-happening-with-pvs-opcodes...-tp19270673p19270673.html
Sent from the Csound - General mailing list archive at Nabble.com.

I don't have max/msp so can't reproduce your circumstances exactly (or 
comment on the max/msp opcodes), so it would be handy to have a URL for 
your source soundfile.

However, the general story with all things pvoc is that (in the absence 
of highly esoteric and advanced (some of it patented) stuff!) all and 
any frequency modifications to pvoc frames will throw the bin phases out 
of alignment to a greater or lesser extent. This is the famous/notorious 
"phasing problem" with pvoc, heard most obviously on percussive sounds. 
I note that your params to pvscale amount to a no-op (ratio 1.0), so 
pvshift is the only opcode making frequency changes. Your source sound 
would seem to have just such a hard attack transient, and (especially 
with long analysis windows) it would then not be unexpected to get some 
blurring.

The primary solution to this is usually some form of peak tracking of 
partials (significant increase in CPU load), and Victor will very likely 
have much more to say about that; but you may well find that reducing 
the analysis lengths will reduce smearing. There does not seem to be a 
significant LF component in the source (the usual reason for using large 
FFT windows), so as a guess you should be able to reduce by at least a 
half before losing frequency resolution.

Richard Dobson



peiman wrote:
> Hello,
> 
> I'm making some sound examples with the pvs opcodes for a sound quality
> comparison with the native fft objects in maxmsp (I'v always thought that
> csound sounds better but now is time for the real experiment!). 
> 
> I've just encountered a subtle but strange artefact with pvshift. Listening
> to the audio example I made earlier
> http://idisk.mac.com/peimankh/Public/pvstest.aiff you will notice that the
> very end part of the file sounds blurry (fft artefact) compared to the
> beginning of the file. This is despite the frequency shift being set to +160
> for both parts (after a krate change in the middle). So it seems that
> changing the shift parameter in krate somehow messes up the timing of the
> fft windows and the resynthesis gradually degrades. Maybe I'm doing
> something wrong, any insights would be most welcome.
> 
> You can see my analysis settings from the instrument bellow...
> 
> Many Thanks
> Peiman
> 
> ain1,ain2	xin
> ain1 	butterhp	 ain1, 20 ;remove dc
> ain2 	butterhp	 ain2, 20
> ftps1  pvsanal   ain1, 4096, 4096/4, 4096*2, 1 ; analyse
> ftps2  pvsanal   ain2, 4096, 4096/4, 4096*2, 1
> 
> fscale1  pvscale   ftps1, 1.0, 0        ; transpose
> fscale2  pvscale   ftps2, 1.0, 0
> 
> fshift1 pvshift fscale1, gk_blue_auto0, 0.0, 0
> fshift2 pvshift fscale2, gk_blue_auto0, 0.0, 0
> 
> aout1  pvsynth  fshift1                      ; synthesise
> aout2  pvsynth  fshift2      
>                                        
> xout	aout1,aout2
>    

Hello,

Thanks very much for the clarification. The sound I posted was  
modified in csound rather than maxmsp. This is the max thread that  
started the whole thing:

http://www.cycling74.com/forums/index.php? 
t=msg&th=35236&start=0&rid=0&S=28bc6cc331c17e17f131ac2181a32bf3

I'm not actually making the max examples myself as I've very little  
experience of fft in max, its a shared experiment with Alex Harker  
from the msp list. We'll have to check if max keeps the phase  
information or not. So far though we haven't noticed any significant  
differences in sound quality. More complex operations remain to be done.


Thanks again
Peiman




On 3 Sep 2008, at 11:05, Richard Dobson wrote:

> I don't have max/msp so can't reproduce your circumstances exactly  
> (or comment on the max/msp opcodes), so it would be handy to have a  
> URL for your source soundfile.
>
> However, the general story with all things pvoc is that (in the  
> absence of highly esoteric and advanced (some of it patented)  
> stuff!) all and any frequency modifications to pvoc frames will  
> throw the bin phases out of alignment to a greater or lesser  
> extent. This is the famous/notorious "phasing problem" with pvoc,  
> heard most obviously on percussive sounds. I note that your params  
> to pvscale amount to a no-op (ratio 1.0), so pvshift is the only  
> opcode making frequency changes. Your source sound would seem to  
> have just such a hard attack transient, and (especially with long  
> analysis windows) it would then not be unexpected to get some  
> blurring.
>
> The primary solution to this is usually some form of peak tracking  
> of partials (significant increase in CPU load), and Victor will  
> very likely have much more to say about that; but you may well find  
> that reducing the analysis lengths will reduce smearing. There does  
> not seem to be a significant LF component in the source (the usual  
> reason for using large FFT windows), so as a guess you should be  
> able to reduce by at least a half before losing frequency resolution.
>
> Richard Dobson
>
>
>
> peiman wrote:
>> Hello,
>> I'm making some sound examples with the pvs opcodes for a sound  
>> quality
>> comparison with the native fft objects in maxmsp (I'v always  
>> thought that
>> csound sounds better but now is time for the real experiment!).  
>> I've just encountered a subtle but strange artefact with pvshift.  
>> Listening
>> to the audio example I made earlier
>> http://idisk.mac.com/peimankh/Public/pvstest.aiff you will notice  
>> that the
>> very end part of the file sounds blurry (fft artefact) compared to  
>> the
>> beginning of the file. This is despite the frequency shift being  
>> set to +160
>> for both parts (after a krate change in the middle). So it seems that
>> changing the shift parameter in krate somehow messes up the timing  
>> of the
>> fft windows and the resynthesis gradually degrades. Maybe I'm doing
>> something wrong, any insights would be most welcome.
>> You can see my analysis settings from the instrument bellow...
>> Many Thanks
>> Peiman
>> ain1,ain2	xin
>> ain1 	butterhp	 ain1, 20 ;remove dc
>> ain2 	butterhp	 ain2, 20
>> ftps1  pvsanal   ain1, 4096, 4096/4, 4096*2, 1 ; analyse
>> ftps2  pvsanal   ain2, 4096, 4096/4, 4096*2, 1
>> fscale1  pvscale   ftps1, 1.0, 0        ; transpose
>> fscale2  pvscale   ftps2, 1.0, 0
>> fshift1 pvshift fscale1, gk_blue_auto0, 0.0, 0
>> fshift2 pvshift fscale2, gk_blue_auto0, 0.0, 0
>> aout1  pvsynth  fshift1                      ; synthesise
>> aout2  pvsynth   
>> fshift2                                             xout	aout1,aout2
>>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"