Routing doesn't work with sources/destinations contain utf-8 symbols #1119
Comments
|
Hello. My initial tests: The good news is that non-UTF8 characters seem to be working OK. Save and load are OK. (Hm, the lines are supposed to be different colours. Broken drawing?) In the screenshot, I do not have any Jack Audio terminals with non-UTF8 characters Therefore I must suspect that there might be a bug in our specific code section(s) In the screenshot, even though I am in an en-US locale, I am temporarily using |
|
My system locale is zh_TW.UTF-8, shouldn't the broken jack port name
(shown in my screenshot) be UTF-8?
…On 2023/4/17 8:01, Tim wrote:
Hello. My initial tests:
Screenshot_20230416_194039
<https://user-images.githubusercontent.com/5422362/232349804-8dcf4840-7c51-4328-82ce-97633abd8851.png>
The good news is that non-UTF8 characters seem to be working OK. Save
and load are OK.
I was worried that it might be broken.
(Hm, the lines are supposed to be different colours. Broken drawing?)
In the screenshot, I do not have any Jack Audio terminals with
non-UTF8 characters
like your screenshot. So I could only test renaming a couple of tracks
to non-UTF8 characters.
I must see if I can tell Jack to rename some ports to non-UTF8
characters so I can test that part.
Maybe the Jack Meta system will help.
Therefore I must suspect that there might be a bug in our specific
code section(s)
that work with Jack port names, such that by the time the router
displays the names
in the 'Jack' source/destination sections, they are mangled.
Because so far */some/* of the other router source/destination types
seem OK.
In the screenshot, even though I am in an en-US locale, I am
temporarily using
a French c locale /and/ application locale for testing some other
locale bugs.
So this bug report comes at an interesting coincidental time.
—
Reply to this email directly, view it on GitHub
<#1119 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFKCVURHCDGDLLX4AQBWWTDXBSB5LANCNFSM6AAAAAAXACI3SI>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Sorry I was probably confusing terms. |
|
I did a test. I added some wide characters to the upstream routes Jack audio port names. Can you do some more checks for me? I need to know if other routing items are working for you. Then, open the router and see what happens. Thanks. |
|
OK, I have created some track contain wide characters: |
|
I tried the latest AppImage release (4.1), the problem still exits. |
|
When I open the router, I found the console shows: I don't know is that related to this issue. |
|
Thanks very much for the tests. I looked very deep into the router source code yesterday. Are you able to build from github master source? |
|
Are you able to build from github master source?
Sure, I can try building form source after I get off my work.
If I push a few debugging output lines into the code base just for
you, are you able to test?
I think yes, if I can compile MusE successfully. I think we can try
this first. If things get complicated and you need to debug on my
machine, I can allow you to remote control my PC for a period of time.
…On 2023/4/18 0:12, Tim wrote:
Thanks very much for the tests.
Hm, that pipewire output looks suspicious, especially since it happens
when you open the router.
I looked very deep into the router source code yesterday.
The missing connection lines are a big clue.
These lines do not depend on the text being correct, they simply
depend on the
routes being there. Clearly the bottom list is able to show the routes
do exist,
but not the connection lines. This suggests invalid Jack ports, rather
than incorrect text.
Are you able to build from github master source?
If I push a few debugging output lines into the code base just for
you, are you able to test?
(This would be the next best thing to me being there - remote debugging!
Apps like Team Viewer also come to mind.)
—
Reply to this email directly, view it on GitHub
<#1119 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFKCVUQTUMMZIGN5RYMEOWTXBVTVNANCNFSM6AAAAAAXACI3SI>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Hi, I have built MusE from source (master branch) sucessfully.
於 2023年4月18日 上午12:12:06 [GMT 08:00]，Tim ***@***.***> 寫到：
…Thanks very much for the tests.
Hm, that pipewire output looks suspicious, especially since it happens when you open the router.
I looked very deep into the router source code yesterday.
The missing connection lines are a big clue.
These lines do not depend on the text being correct, they simply depend on the
routes being there. Clearly the bottom list is able to show the routes do exist,
but not the connection lines. This suggests invalid Jack ports, rather than incorrect text.
Are you able to build from github master source?
If I push a few debugging output lines into the code base just for you, are you able to test?
(This would be the next best thing to me being there - remote debugging!
Apps like Team Viewer also come to mind.)
--
Reply to this email directly or view it on GitHub:
#1119 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
|
Thanks. |
|
Hello @ChihHao-Su Sorry for the long delay. I have reproduced the problem. And I have found the trouble. Changed all QString::toLatin1()/tolocal8Bit() usages to QString::toUtf8() in the following files so far: Try it and let me know if any more trouble. Hope that helps with the issue so far. Good luck. |
|
Hi, It seems that things get worse after pulling the master branch. When I startup muse4, I got: There's a lot of "jack connect <xxxxx> - <yyyyyy> failed with err:22" which are abnormal, others are just fine. And, I cannot connect ANYTHING in muse to jack ports in muse4. For example, I have:
But the graph in qjackctl shows:
Now the only way to get output of muse form my device / get input in muse form my device is to connect them in qjackctl manually. |
|
Hi @ChihHao-Su . I need to ask: Do you recall, about the text that was posted (the text with all the error 22), I am asking because there is something strange about the text vs. pictures. About the textual jack connect errors:We usually see error 17 (it is normal and means the connection already exists). Both "jack-midi-1_out" and "CASIO USB-MIDI 2:(playback_0) CASIO USB-MIDI MIDI 1" do exist So I am puzzled by this. And last... what about the original issue, the utf8 characters? Is that working now? Thanks for your help. |
|
Sorry for the super LONG delay due to something happened to my home town. After I came back, I did a full-system upgrade, I upgraded my system to Fedora 38, and it's pretty weird that the problem is gone, master branch works fine on my PC with UTF-8 jack devices, I can establish connections between tracks in muse and jack ports. I did nothing to my system configuration, hardware (include my midi devices). I think it might be some bug occurred by some packages were not up to date (mixing old and new packages) or just some problem in older version of Fedora.
Yes, the text and the image below are from the same session. That also confused me cause I cannot find "pw-SomeThing" anywhere. I have no idea about why it appears.
I'm sorry that I cannot verify anything now, 'cause I cannot reproduce the problem. This is the output now: Anyway, the issue about routing of jack ports contain UTF-8 characters is gone. I must thank you for your help and patience.
Thank you very much. |
|
Thank you. |
Target version
MusE 4.1 Flatpak
Describe the bug
In the destinations and sources diagram (the upper part of the dialog), all non-latin charaters turn into
?.Click a row in the distinations and sources table (the lower part of the dialog), MusE cannot show the corresponding distinations and sources linkage on the destinations and sources diagram.
Expected behavior
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: