different responses on Onsets with Windows 64-bit build made with MSYS/MinGW and on one build with MSVC

[enrike]

the output of Onsets class on a Windows 64-bit machine running a Supercollider 3.9dev build made with MSVS is much worst that with the same version but made with MSYS/MinGW. The first one constantly drops a lot of the incoming onsets in a very random way.

This is the code for testing

(
b = Buffer.alloc(s, 512);
x = {
	var sig, chain, onsets, pips;
	sig = Decay2.ar(Impulse.ar(1, 0.25), 0.01, 1, mul: SinOsc.ar(mul: 0.1));
	chain = FFT(b, sig);
	onsets = Onsets.kr(chain, threshold: 0.2, odftype: \rcomplex);
	pips = WhiteNoise.ar(EnvGen.kr(Env.perc(0.001, 0.1, 0.1), onsets));
	Out.ar(0, [sig, pips]);
}.play;
)

[nhthn]

the onsetsds code is pretty big, but it is deterministic. i would approach it by starting with the shortest possible deterministic input signal that reproduces this behavior (like just 1024 samples or something), then use wolf fence debugging to locate the first point where the math diverges.

[mossheim]

There are two #defines that get switched on for msvc in the relevant TU; one for hypotf and one that undefines inline. It seems like both are unnecessary in VS2013+ (https://msdn.microsoft.com/en-us/library/a9yb3dbt(v=vs.120).aspx). @enrike, which version of msvc are you using? Could be a problem with their headers.

[bagong]

enrike didn't build, I did. I once removed this c99 related stuff, or anything that made msvc special in that code line. Didn't make a difference. But you're right, they are not needed any more (at least the build doesn't break without them)

[mossheim]

@bagong, thanks for the info. if you read the documentation I provided above, it says that the underscore-prefixed versions are identical to the standard-name functions. which VS edition did you build with?

[bagong]

Possibly not 2013, I think 2015.

[mossheim]

OK! I will check it out next time I have my windows machine booted. To clear up any confusion, I'm talking about the implementation for hypotf provided by the msvc compiler, which will be different from (though hopefully equivalent to) gcc's. From what I've read on the mailing list, it sounds like the problem lies there. It may be that for some set of inputs (denormalized floats or 0 or inf or nan) the behavior diverged because it's loosely defined by the standard.