OpenMPT, as an ANSI application, does indeed have various issues with unicode filenames (see f.e. here: http://forum.openmpt.org/index.php?topic=2217.0). To circumvent your problem, you could enable OpenMPT's portable mode (as described here: http://forum.openmpt.org/index.php?topic=4350.0) and store OpenMPT in a path that doesn't contain non-ASCII characters.

LOL you post before me x) so fast enough. BTW: What is required to handle unicode?

Thx a lot, it really help me.

Just wanted to report this happens with dragging and dropping in midi files from Windows Explorer which have Japanese characters in the path, in version 1.22.05.00. Mildly annoying as I have to temporarily copy it to "temp.mid" or the like first. Hopefully this will be fixed at some point.

It happens with anything, not just MIDI files (which you shouldn't listen to with OpenMPT anyway). There might be a fix soon-ish, but no idea when that will happen exactly.

Indeed I shouldn't, but I often import MIDIs. Or just quickly load them up to take a glance at the notes. This was simply where I noticed it happen.

We've made some progress recently in supporting unicode filenames in as many places as possible. There are some tricky bits that will be difficult to fix (if it's possible at all), but some parts of the application can deal with unicode filenames now:

• Adding plugins via the plugin manager.
• Loading and saving plugin presets.
• Loading / saving samples and instruments via the editor or drag'n'drop.
• Keybinding configuration.
  Drag'n'drop and loading modules from unicode paths doesn't work yet (difficult to fix) and the positions of the main toolbar and related stuff cannot be saved properly if mptrack.ini is placed in a unicode path (also difficult to fix).
  If you'd like to try out the latest progress, check out http://sagagames.de/stuff/mptrack.exe

We've made more progress with regards to unicode path names during the last week. Re-download the executable from the link above to give it a try; this version can now also finally load modules from unicode paths. The autosaver is now also unicode-aware. Toolbar positions and the MRU list still cannot be saved if the .ini file resides in a unicode path, though.

Gave it a quick test and looking good - can load both .it and .mid files with Unicode characters in them. Also able to save a .it file with a filename and in a folder name with Unicode characters.

One minor flaw though is that if I have a Unicode-named file open and click Save or press Ctrl-S, instead of Save As, the Save As dialog box appears regardless - with an ASCII pathname it just immediately saves the file. It will let you overwrite the existing file though so just a minor inconvenience.

Thanks for the hard work on this :)

Keiji, I will look into the Save/SaveAs problem tomorrow.

Keiji, http://buildbot.openmpt.org/builds/auto/openmpt/openmpt-r3257.7z should work as one would expect now when you click Save or do any equivalent, thanks for reporting.

Update: MRU list is now also unicode-aware.

Dragging Unicode filenames on mptrack.exe still does not work.

For this to work, we have to create our own CCommandLineInfo that does more than just overriding ParseParam().

Good news: OpenMPT compiles cleanly as a Unicode application now. However, we have not tested this very extensively yet, and it's likely that it's still blowing up in some spots, so we will most likely only enable this for OpenMPT 1.28 but not for OpenMPT 1.27. Maybe we should also provide some Unicode test builds (not necessarily through buildbot just a manual build every week or so) so that users can help spotting those spots.

I think this issue can be closed at the same time that we decide to actually make Unicode release builds.

As I think it's safe to say now that 1.27 release builds will be UNICODE, we can resolve this issue. Any new unexpected problems may still be reported in separate issues.