Re: [Audacity-devel] Risset drum, was Re: Vocoder, Nyquist, decimals and commas

[Roger D. <rb...@cs...>]

I'm not sure what is the problem, but I gather you want to change the 
locale from "C" to something else without breaking Nyquist. I'm not sure 
what the Nyquist behavior should be in that case. Certainly, XLISP 
programs should keep the period as decimal separator, but what about 
other cases? It looks like Nyquist converts floats to strings for 
plotting and for general output, and from strings to floats for sliders. 
Since LISP blurs the distinction between programs and data (e.g. 
GRINDEF, which prints function definitions, uses the same floating point 
print routine as PRINT), I think it would be a mistake for XLISP to 
format floats or read them in the local convention by default, although 
it could be useful (maybe essential) to allow programs to explicitly use 
local conventions. This sounds like the opposite of what Audacity wants: 
default is to follow local conventions, and using "C" locale is an 
explicit override. Am I right in concluding that these approaches are 
incompatible and that's the real problem? If so, the fix would be to 
either (1) change Audacity to use a non-"C" locale only where it's 
needed (but I'm guessing this might be hard because it permeates the 
large wxWindows library) or (2) change Nyquist to use "C" conventions 
almost always even though the locale is set to something else. I'm not 
sure how to do that, but I think there are relatively few important 
calls to printf/scanf/atof that would be affected.

-Roger
>
> @Roger Dannenberg: The reason why a working locale-independent Nyquist 
> is so difficult for us to implement is because Nyquist breaks when 
> LC_NUMERIC is not set to "C". E.g., if LC_NUMERIC is set to a value 
> where comma is used as a decimal separator, printf() and scanf() will 
> output/expect numbers like "1,23" instead of "1.23". The only 
> workaround is to use locale-independent functions for converting 
> from/to numbers (this is how we do it in Audacity, anyway). Are you 
> already aware of this problem? How do you solve this with "normal" 
> Nyquist?
>