yes, but wouldn’t it be nice if windows actually had UTF-8 support all the time and we didn’t have to deal with this? Admittedly I always test for this when I do file IO, but not everybody does, and what a pain to do all those conversions in windows.
The comma is less likely to be a problem (if it’s an ASCII comma). The issue is that Rack is internally utf-8 based for strings, like most Linux-based software. Linux is a utf-8 OS.
Windows is more complex. It is fundamentally UTF-16 (Unicode), but it has a compatibility API (A) that is ANSI (codepage-based). Rack APIs that interface with Windows convert strings to and from Unicode and use the Unicode (W) API, which is “correct”.
The problem arises with plugins that use libraries (or directly) that pass internal utf8 strings directly to Windows ANSI (A) API. The A API internally uses the current system codepage to convert those bytes to Unicode and calls the W API. When the current system codepage is not utf8 (which is generally true), the string is converted incorrectly, resulting in the file not being found because the names don’t match.
Users that don’t have non-ASCII user names often don’t see the latent issue, but this is mostly luck.
The workaround changes the system codepage to utf8, which allows the invalid implicit assumptions made by the plugin or its library to be true, and then everything works.
Comma is a legal file name character, but is misunderstood by command.com and possibly other utilities.
Perhaps not of much importance now, the character quoted above is not a comma, but a “‚” SINGLE LOW-9 QUOTATION MARK.
That one would be a problem!
That setting for utf8 system codepage will be turned on by default eventually. Might even be for recent Win11. The reason it hasn’t changed is that it’s a breaking change for some scenarios and there is huge enertia in the corporate world.
Unfortunately, this isn’t a complete solution for full parity for utf8, because there are some APIs that are hamstrung in the A version, and not simply a string-converting wrapper. Thankfully there aren’t too many of these.
Not exactly. The comma serves as a token delimiter under various contexts with command.com command line and batch scripting. But as long as it is enclosed within double quotes, a comma works just fine within a file name, or any other context. However, enclosing within quotes can be awkward in some esoteric scenarios.
To me, it’s still misunderstood. You clearly disagree. That’s fine.
Bret, Omri appreciate your work on ArpSeq. It is a very useful and creative tool. One suggestion. Could you please add a feature that allows us to animate the start/end positions of a loop? I think this would make ArpSeq even more versatile and fun to use.
My apologies for not jumping in sooner! Thank you to the community for answering @obywatelk 's problem. I’ve heard that before, and it’s great to have a solution now!!
@impersonalis, I love that idea. I may not implement it directly, but you can use storermelder’s 8FACE or 8FACEx2 to achieve that!
Sure, 8FACE module is great, thank you. I presume that making that sliders and GUI elements ‘compatible’ with Stoermelder’s CV-Map module might not be a straightforward task without a complete code overhaul. Regardless of the impressive capabilities of Stoermelder’s modules, I personally hope to see the addition of ArpSeq companion/expander module.
Module authors don’t have to do that. Rack’s file functions do the right thing for you.
So if you are a sampler and you need to open of files outside of rack there is a rack API to do that? is that what asset::system() does? But these functions return 8 bit strings - you can’t pass those to open() can you?
In any case, sounds like there are some cool APIs somewhere that keep you from having to deal with UTF-16. Could you tell me which APIs are the ones for this?
This is really a discussion for Development now.
asset::system gives you the path to the Rack system folder. asset::user gives you paths under the Rack user folder.
Use the functions in the ::rack::system namespace for dealing with paths, (e.g join) directories, and reading/writing files, Declared in Rack\include\system.hpp
for example,
std::vector<uint8_t> readFile(const std::string& path)
void writeFile(const std::string& path, const std::vector<uint8_t>& data);
Includes archiveDirectory and unarchiveDirectory
Oh, that’s cool. I never knew about that. Of course the vast majority of my modules were for Rack 0.6 and Rack 1.x, so back when I needed to do a lot of file I/O these functions didn’t exist! tx for pointing them out.
Well, welcome back to making modules!
** Update: I misread your message. It would be quite difficult to make those sliders and GUI elements CV compaible with the CV-Map module. However… I have been working on a new framework for drawing LCD style interfaces, and I’ll see what I can do.
I made you a demo that you probably don’t need. Ha ha ha:
Thanks, Bret 
If it movable it should be CV’able (kind of motto) 
I couldn’t agree more. 
However, please be patient with me! I’ll do my best!
I am not exerting any pressure. If my previous message gave such an impression, I apologize for any misunderstanding.