Hi Tim,
2015-03-18 3:21 GMT+01:00 Tim E. Real <[email protected]>:
> On March 17, 2015 09:54:14 PM Robert Jonsson wrote:
> > 2015-03-15 18:06 GMT+01:00 Robert Jonsson <[email protected]>:
> > > 2015-03-15 16:57 GMT+01:00 Andrew Deryabin <[email protected]>:
> > >> Hi Robert,
> > >>
> > >> Just made tests with new fuid synth patches:
> > >>
> > >> I have LANG set to ru_RU.UTF-8
> > >>
> > >> 1. Loading sf2 banks from paths formed from english characters works
> > >> fine.
> > >> 2. But when there is international characters found in the paths
> nothing
> > >> happens at all, and moreover after that 1 case stops working too.
> > >>
> > >> How to test:
> > >>
> > >> Create folder with unicode name:
> > >>
> > >> Банки SF2
> > >>
> > >> Then copy some soundfonts here, set LANG to ru_RU.UTF-8, load MusE and
> > >> try to
> > >> open these sound fonts from that path.
> > >
> > > Alright, no time (or energy for that matter ;) to test this now but I
> will
> > > test and compare!
> >
> > This is so wierd. I created a folder Банки SF2 and followed the data in
> the
> > debugger. Mess synths pass data to the synth as a sysex datastream, so
> the
> > string had to be serialized, transferred and deserialized again. Turns
> out
> > I had been using toLatin1 here for whatever reason.. it had worked for my
> > previous paths.
> > For good reason it did not work here, instead I tried changing to toUtf8
> > and QString::fromUtf8 and according to the debugger in Qtcreator the
> string
> > that turns up on the synth side contains the right string. But
> > QFile::exists(string) does not recognize that this path points ot a valid
> > file. Maybe the debugger is fooling me?! So as a test I bypassed this
> > transfer and kept the original path in a global QString, now the
> > QFile::exists(string) works, later on the toLocal8Bit also works and
> > fluidsynth loads the soundfont!
> >
> > Basically I hate encodings ;-P It seems it always a matter of trying all
> > the combinations..
>
> Some of this may be my (English) fault, desiring just pure 'Western' text
> for printf checkpoints and so on - /somewhat/ propagating Latin1 usage.
>
> Using an example of a plugin with foreign language characters in its name,
> there are two pieces of text to keep handy:
> 1) We need to keep the original text in its original language so that
> when the name is stored, for example in the song file, it is not mangled
> by local translations or neutered by 8-bit conversions.
> 2) We need a localized readout of the name, if the user desires. Staring
> at such a plugin name would make me think "can I get a rough translation?"
>
> We may be *doomed* here, because char strings and Latin1 strings are used
> extensively in MusE.
>
> Our XML module (xml.cpp) is not internationalized - it writes char strings
> !
>
> I direct your attention to Werner's replacement (from muse_evolution) in:
> al/xml,cpp
>
> I looked at the situation. It obviously would require /extensive/
> modifications
> to our code in order to support Werner's XML module.
>
> But, there it is.
> And then there's the rest of MusE to deal with...
>
> The work I did in this area concerned international numerals - floats etc.
> I tested the code and it worked and fixed the reported issues.
>
> But I don't recall if I tested storing international text - letters etc.
> I'm thinking now that MusE can't possibly be doing it correct - if at all.
> I mean, I /have/ tested opening MusE under a different language setting,
> and I think we all know that seems to work fairly well.
>
> Robert and Andrew, what can you report about experiences with MusE,
> particularly saving and loading international (non-Latin1) text such as
> a plugin or the example given by Andrew?
>
It might be that some parts are doomed to never work with non Latin1
characters but mostly it does not bother me.
The parts where it becomes necessary is when dealing with the file system
and, to some extent, dependencies. I'm not sure, possibly jack supports
naming connections with international characters but I would not bet on it.
There are some LADSPA plugins with a decimal point in the file name that I
reported about earlier. The decimal point was silently converted to a
decimal comma for me, causing crashes. That particular problem vanished
though, I would guess it was a OS bug that got fixed. Or some wierd
configuration on my computer..
Otherwise it's so unheard of with plugins with international chars that in
reality it's not a problem.
Dealing with the file system is where the real problems lie, paths with
international characters. I haven't tested all kinds of file interaction so
there may be other places where it fails but I think (for now atleast) the
toLocal8Bit will do the trick. Although Andrews cyrillic path isn't
completely solved yet but I still think the problem is different as I got
it to work when bypassing the sysex serialization and directly doing
toLocal8Bit when loading the soundfont.
To be continued
Regards,
Robert
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
