Turned out to be a Linux x86_64 problem only. Worth explaining what's going on here - among all the "usual bugs" this one is pretty rare and shiny, from a technical point of view

Problem is that glibc's "pow" function gets really slow (really really goddamn slow), depending on which values you feed it with (well-formed floating point numbers, not denormal numbers or such).

When automating resonance in Renoise's Moog LP the following statement is applied along the line:

pow(1.0 + r*4.0, 0.45); // with r >= 0 <= 1

If r goes down to zero, which happes in this example song, pow's first parameter goes down to 1 and glibc's x86_64 pow impl starts getting slower and slower. Extraordinary slow at some point, which then leads into XRUNS.

Here's some guy with the same problem, examples and a few more infos: http://entropymine.c...rsener/slowpow/

EDIT: Oh it's actually documented now http://man7.org/linu...an3/pow.3.html:

On 64-bits, pow() may be more than 10,000 times slower for some

(rare) inputs than for other nearby inputs. This affects only pow(),

and not powf() nor powl().

We can of course work around this in this special case, but this is a general problem with pow on Linux then, so it needs a general solution. Will do more tests and research here...