[PD] readsf~ harddisc access [denormals once again]

[Johannes Burström]

thanks for all the help so far. It seems like devel_0.37 might be a good 
thing, but unfortunately i'm a complete newbie in terms of compiling my 
own pd. The best thing would of course be a compiled-and-ready package, 
but that might be asking too much. I don't mind learning something new, 
but I just don't know where to start looking.  I'm on windows (xp), i do 
have an installation of VC++ 6.0, have downloaded the source code, have 
browsed in the cvs and googled around just to make sure i'm not missing 
something obvious, but now i'm stuck. Any help would be great.

Johannes

derek holzer wrote:

> Tim Blechmann wrote:
>
>>
>> one possibility is to add noise of about 1e-10 ... also the PD_BADFLOAT
>> macro that's supposed to flush denormal numbers to zero ... but it's
>> only killing numbers that are already denormals... i'd suggest to use
>> the devel_0_37 branch since it contains a small patch that flushes
>> almost denormal numbers to zero ... it helped to reduce cpu spikes on my
>> p4 ...
>
>
> Yes, you should certainly try the devel_0.37 and see if it helps you 
> out. Dealing with denormals is quite difficult, and Intel has no plans 
> to correct this problem any time in the future, so either people have 
> to not buy Pentium processors for audio work, or programmers need to 
> account for this problem in their code. Since a lot of programmers I 
> know don't have a P4 handy to test on all the time, it makes it 
> difficult. Trust me, PD is not the only program which suffers from 
> denormals.
>
> Denormals tend to happen in two places: in filters, where certain 
> frequency componants are greatly attentuated, leading to very low 
> sample values, and in any kind of feedback situation where the signal 
> is attenuated over time [classic example is the tail of a reverb or 
> delay]. Since the denormals happen *inside* the objects, you have to 
> add whatever "safety noise" in at a point where it will remain present 
> whereever denormals may occur, but I think it would be impossible to 
> catch every place where you might get them. In a feedback delay patch, 
> for example, you might have to add it *after* the attentuator for the 
> signal which is fed back into the system.
>
> For filters, you don't have much of a choice. The attentuation happens 
> inside, so their code must be written to handle denormals. I know for 
> a fact that the standard high, low and band pass filters in Miller's 
> PD do not take denormals into account, for example. It is one of the 
> big weaknesses of digital filters [at least on a P4], along with the 
> possibility of "blowing up" when you run too much signal through them 
> [see C. Roads "Computer Music Tutorial" or Boulanger ed. "The CSound 
> Book" for big discussions on digital filters].
>
> good luck,
> d.