This may be a localization problem, but I wanted to share as I spent half a day figuring out what was happening…
I have float values stored in an xml element inside my plugin (this is for factory preset value). (So they are stored as string like “0.707”).
Now to retreive the value of each string attributes from my xml, I use getAttributeValue().getFloatValue(), which work fine in most host. I get my string i.e. “0.707” converted to a float 0.707
But in plogue bidule, it always convert the string to float 0, because the comma is not used the same way.
Bidule expect 0,707 and not 0.707
If I to do this : getAttributeValue(i).replaceCharacter(’.’,’,’).getFloatValue()
in order to ‘prepare’ the string data before the conversion to float, then it works in bidule, but now it broke all other hosts (they will convert to 0).
So my question is how to handle this automatically ?
Thinking about is, this is actually quite a nasty problem. I guess bidule must be mucking about with the c library’s locale setting, and that’s breaking atof, which in turn breaks String::getDoubleValue(), which is used all over the codebase.
Luckily, atof is only called in one place in juce, so I only need to fix one function to sort it out… but annoyingly, it looks like I’ll have to write my own atof for it, which is a bit fiddly.
I did solve this issue by always calling this at the beginning of my applications:
This way, all floating point numbers are always written with decimal dot and not commas within my application, regardless of the locale set by the host application (I had this problem with ProTools, not with bidule, but I bet it is the same).
That’s not a very good solution, because it’ll probably break bidule’s own internal string conversions, and who’s to say whether bidule (or some other host) will repeatedly keep changing the locale…
But don’t worry, I’ve just checked in some new code with a locale-independent number parser! Have a go and see if it helps.
