Is it normal that the DSP EQ does display the values using “,” (comma) which is ok on a german windows, while if I want to enter a value I must use “.” (dot) which then in return gets dispalyed as a “,” again?
A unique behaviour roon shows. I remember some old programs build by programming environment way back before multilingual and unicode handling got implemented in a way which doesn’t ask the coder to take care of since it’s all automated by reading system settings.
Took me a while to get what happened since it shows weird results if you enter a value with a comma instead of using a dot.
core on a synology nas
roon on win10 x64 (german location/currency/langauge settings)
Screenshots? Won’t help much, since you’ll see what I see and the screenshot won’t tell you if I had pressed a “,” or a “.”
steps is an easy one
fetch a playback device … open up DSP … dive down to eqaulizer
and when you fiddle with the values of the 5 bands and want to enter a value being displayed in the form
1,00 and you want to make 1,10 you enter
which results in something strange happening while if you enter
the value displayed turns in to 1,00 and all works
means the roon software mixes up the OS wide rules for delimiters and such like which are language/region specific. You you are aware delimiters aren’t identical globally? 1.000,12 € is a thousand, and 12 cents while
1,000.12 $US is likely the same in US dollars but with swapped , and . delimiters. That’s the issue.
It wouldn’t be an issue if soon would have implemented it the WYSIWYG way since if I see a . I would enter a . but if one gets shown a , one tends to enter values the way they were presented.
If someone starts looking into this, he could perhaps have a closer look why for example the pretty common value TAB value TAB value sequence doesn’t work either, which is the most common way to adjust multiple values in separated input boxes in one go.
roon requires a value RETURN value RETURN … which then asks to put the pointed into the next input field manually.
Looks as if the code doesn’t catch the so called focus_lost event which normally results in storing the actual value as does a return press, but also jumps into the next field allowing to modify it’s value straight.
Thank you for the follow up and providing the requested feedback @StefanB!
Continuing forward, I have passed the information provided above over to our teach team for evaluation/testing and once my report has been updated/passed back I will be sure to share the team’s findings with you asap.
Your patience during this process is appreciated, thanks!