CJK characters in WASAPI audio device name is broken displaying.

Thanks for reporting Kenzi!

Gosh, I don't know how easy it will be for me to fix this issue, since I would have to set myself up with a windows computer with everything in japanese just in order to debug the problem.

Unfortuantely, I don't know much MuseScore can do to solve this problem, because MuseScore is simply just using portaudio/midi to request a list of devices from windows. If those strings have unicode characters from supplemental planes (i.e. they require more than 16-bits to represent), then what I'm guessing happens is either those strings aren't properly handed over, or maybe the QComboBoxes don't know to handle the supplemental planes.

Basically this seems like too hard of an issue for me to fix, and the problem itself is very minor. I'm sorry but you might just have to tolerate the improperly-rendered strings.

I'm going to mark as won't fix for now. If for some reason there are dozens of CJK users who experience this problem and would like it fixed, then I will give it a shot. But without a high demand to fix it I don't see it is worth the effort to debug for now.

I can only looking at the code and guess what is wrong. I notice that both Portaudio::apiList() and Portaudio::deviceList() use QString::fromLocal8Bit() for converting the string received from the api into the string musescore will use:

al.append(QString::fromLocal8Bit(info->name));

That code was by lasconic on May 2016 and in commit bc9bc93 and the purpose was "use local encoding for Portaudio device and api". Previously that line just used the plain char* string info->name directly without using that conversion. I assume lasonic did this to avoid a problem with how strings in different langauges get displayed...and I see that function (https://doc.qt.io/qt-5/qstring.html#fromLocal8Bit) description is:

"Returns a QString initialized with the first size characters of the 8-bit string str." and "QTextCodec::codecForLocale() is used to perform the conversion." ...and the description for that function is "On Windows, the codec will be based on a system locale. On Unix systems, the codec will might fall back to using the iconv library if no builtin codec for the locale can be found."

Interestingly the portmidi code for receiving api device string names, PortMidiDriver::deviceInList() and PortMidiDriver::deviceOutList(), don't use that special QString::fromLocal8Bit function, but rather just use QString(info->name). I'm curious, do the port midi input and output devices look normal or messed up in japanese??? I would think should use the same char* to QString conversion function in both cases, but of course need to figure out what is best. Looking at Qt docs, all the different string conversion functions are:

QString fromCFString(CFStringRef string)
QString fromLatin1(const char *str, int size = -1)
QString fromLatin1(const QByteArray &str)
QString fromLocal8Bit(const char *str, int size = -1)
QString fromLocal8Bit(const QByteArray &str)
QString fromNSString(const NSString *string)
QString fromRawData(const QChar *unicode, int size)
QString fromStdString(const std::string &str)
QString fromStdU16String(const std::u16string &str)
QString fromStdU32String(const std::u32string &str)
QString fromStdWString(const std::wstring &str)
QString fromUcs4(const uint *unicode, int size = -1)
QString fromUcs4(const char32_t *str, int size = -1)
QString fromUtf8(const char *str, int size = -1)
QString fromUtf8(const QByteArray &str)
QString fromUtf16(const ushort *unicode, int size = -1)
QString fromUtf16(const char16_t *str, int size = -1)
QString fromWCharArray(const wchar_t *string, int size = -1)

Considering that the input string from port audio is a char*, that might narrow down the list...but without knowing the true original representation of the sting, it is hard to guess what the best function to us it. My guess would be that the string is sent as Utf8, which is how to represent unicode with 8-bit chars only (in which case unicode may use up to four 8-bit chars to represent a single unicode character.)

Interestingly, it seems the default QString constructor from char* according to https://doc.qt.io/qt-5/qstring.html#QString-7 is converted to Unicode using the fromUtf8() function

I made a test PR https://github.com/musescore/MuseScore/pull/4592 which will generate a Windows musescore test build shortly that I'd like you to test and tell me if the strings are properly converted.

@NOIKE, in the meantime, could you tell me what the output of going to windows power shell on your japanese computer and typing the following:

Get-UICulture

and also:

Get-Host

I recall this problem as well. I think you reported it via Twitter many years ago, and I posted it here somewhere in the issue tracker. So it's still here somewhere.

I am starting a build, this time I'm including debug info with the raw string as a hex array: https://github.com/musescore/MuseScore/pull/4594

Anyone who wants to help me debug, please download the test build from:

https://ci.appveyor.com/api/buildjobs/pgrocfuvrvn1f9kr/artifacts/MuseSc…

And let me know if those strings look better or not.

I did add raw debug output to that build, but have to set the QT_LOGGING_RULES prior to executing. For instance in powershell run

$env:QT_LOGGING_RULES = 'portMidi.debug=true;portAudio.debug=true'

prior to running the test build. Then when open Edit->Preferences, should see a bunch of messages containing the word "appending" and a bunch of random-looking numbers. Those numbers are the raw hex representation of the strings that windows sends through portaudio/midi to musescore...and pasting them here for me to look at would be most helpful in diagnosing the problem.

And I realize there is low priority to fix this, but incase there are anyone else who experiences this problem, please it would be great to provide me the debug information. So I'll change status to "needs info".