Hello everyone,

My questions is this: do k-rate or f-rate operations involving the  
value 0 require more CPU or do normalization issues only arise with a- 
rate signals on intel-based machines?

I am getting some serious glitches in an pvs-based instrument when it  
comes to 0 k-rate values that multiply the amplitude of fft-bins in a  
table (using pvsftr) in a loop block. The CPU usage is fine with  
something like 0.0000001 but as soon as it goes down to zero it spikes.

I have tested this without the actual synthesis (eliminating all a- 
rate output) and the same. So the issue is certainly happening at k- 
rate and/or f-rate.


Thanks in advance.

Best,

Peiman



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

Denormal problems can arise on Intel machines, where any computation 
leads to a ~very small~ (denormal) but non-zero value (most typically, 
as a consequence of a recursive operation). Multiplying by zero itself 
should not cause any problem.

So it can happen anywhere (k-rate or a-rate; the latter presumably more 
quickly) - but it is unusual in a straight non-recursive computation, 
unless you really are multiplying two very small numbers together. A 
classic way to avoid denormals is to add a very small value  (+-1.0e-20, 
or quasi-dither, say) to your data - it will not survive reduction to 
integer samples but will be enough to keep the CPU happy. I have hit 
such problems in pvoc processes, but in each case some recursion was 
involved, such as a decay envelope. If you have nothing like that it is 
more of a mystery, in the absence of more information.

Richard Dobson

Peiman Khosravi wrote:
> Hello everyone,
> 
> My questions is this: do k-rate or f-rate operations involving the value 
> 0 require more CPU or do normalization issues only arise with a-rate 
> signals on intel-based machines?
> 
> I am getting some serious glitches in an pvs-based instrument when it 
> comes to 0 k-rate values that multiply the amplitude of fft-bins in a 
> table (using pvsftr) in a loop block. The CPU usage is fine with 
> something like 0.0000001 but as soon as it goes down to zero it spikes.
> 
> I have tested this without the actual synthesis (eliminating all a-rate 
> output) and the same. So the issue is certainly happening at k-rate 
> and/or f-rate.
> 
> 





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

Peiman Khosravi wrote:
..
> if (kcount < inumbins) kgoto loop
> 
> Yes that makes absolute sense now. I shall get in there and add the 
> values. Can I use scientific notation like +-1.0e-20? Does csound 
> understand these?
> 

Not sure, I thoo9ght it did, but others (John?) will confirm one way or 
the other. Simplest to add the dither constant. More sophisticated 
methods may be indicated (e.g. alternating sign on successive outputs, 
or quasi-dither: 1.0e-20*rand() etc) to avoid the constant itself being 
filtered away, depending on the nature of the process. There is also a 
Csound "denorm" [sp?] opcode, not sure if it is applicable to general 
k-rate data though.

Richard Dobson



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

What about the denormal opcode, isn't that useful?

On 29 Nov 2009, at 21:25, Richard Dobson wrote:

> Peiman Khosravi wrote:
> ..
>> if (kcount < inumbins) kgoto loop
>> Yes that makes absolute sense now. I shall get in there and add the  
>> values. Can I use scientific notation like +-1.0e-20? Does csound  
>> understand these?
>
> Not sure, I thoo9ght it did, but others (John?) will confirm one way  
> or the other. Simplest to add the dither constant. More  
> sophisticated methods may be indicated (e.g. alternating sign on  
> successive outputs, or quasi-dither: 1.0e-20*rand() etc) to avoid  
> the constant itself being filtered away, depending on the nature of  
> the process. There is also a Csound "denorm" [sp?] opcode, not sure  
> if it is applicable to general k-rate data though.
>
> Richard Dobson
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



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

Yes but that is a-rate only.

Now come to think of it, it would be nice to have an f-rate one too.

Best,

Peiman


On 29 Nov 2009, at 21:25, Victor Lazzarini wrote:

> What about the denormal opcode, isn't that useful?
>
> On 29 Nov 2009, at 21:25, Richard Dobson wrote:
>
>> Peiman Khosravi wrote:
>> ..
>>> if (kcount < inumbins) kgoto loop
>>> Yes that makes absolute sense now. I shall get in there and add  
>>> the values. Can I use scientific notation like +-1.0e-20? Does  
>>> csound understand these?
>>
>> Not sure, I thoo9ght it did, but others (John?) will confirm one  
>> way or the other. Simplest to add the dither constant. More  
>> sophisticated methods may be indicated (e.g. alternating sign on  
>> successive outputs, or quasi-dither: 1.0e-20*rand() etc) to avoid  
>> the constant itself being filtered away, depending on the nature of  
>> the process. There is also a Csound "denorm" [sp?] opcode, not sure  
>> if it is applicable to general k-rate data though.
>>
>> Richard Dobson
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



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

Something to avoid if possible. Adding denormal corrections to pvoc 
frames can be expensive. You would need one for each frequency bin of 
interest, which might be all of them, which could amount to quite a bit 
of overhead.

Richard Dobson


Peiman Khosravi wrote:
> Yes but that is a-rate only.
> 
> Now come to think of it, it would be nice to have an f-rate one too.
> 



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

Yes I see. So you would lose more CPU than gaining in the end.


On 29 Nov 2009, at 22:03, Richard Dobson wrote:

> Something to avoid if possible. Adding denormal corrections to pvoc  
> frames can be expensive. You would need one for each frequency bin  
> of interest, which might be all of them, which could amount to quite  
> a bit of overhead.
>
> Richard Dobson
>
>
> Peiman Khosravi wrote:
>> Yes but that is a-rate only.
>> Now come to think of it, it would be nice to have an f-rate one too.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



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

Well, no, full-on denormalization can bring a process (and a whole 
machine) to its knees (certainly take it out of real-time performance); 
if you need it you need it, but if there is any way to rejig the 
algorithm etc to avoid it, or to use it at a low rate, use that even if 
it adds complexity. Clamping small values to zero can sometimes be a 
cost-effective solution; "it all depends". Test your algorithms (if you 
are not already doing so) by feeding in some periods of silence; that is 
typically when denormals assert themselves. The main reason people use 
simple addition of small values (algorithm permitting) is to avoid 
conditional tests per sample, which is a good way of slowing things 
down. You may want to try all available solutions, including the global 
addition, and see what works best.

Richard Dobson


Peiman Khosravi wrote:
> Yes I see. So you would lose more CPU than gaining in the end.
> 
> 
> On 29 Nov 2009, at 22:03, Richard Dobson wrote:
> 
>> Something to avoid if possible. Adding denormal corrections to pvoc 
>> frames can be expensive. You would need one for each frequency bin of 
>> interest, which might be all of them, which could amount to quite a 
>> bit of overhead.
>>



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

OK so I just added a small amount to the multiplier value and it's  
working fine now! Here was the problem. I was creating a pvs signal  
(by writing values to a table) to be multiplied with another (using  
pvsfilter). Now all I have to do is make sure that the values in the  
first table never go lower than 0.0000001 and all is well. No sudden  
CPU spikes.

Thanks very much for your help.

Best,

Peiman

On 29 Nov 2009, at 23:08, Richard Dobson wrote:

> iods of silence; t



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