Segmentation fault - When transfering sample named with Chinese Characters

[chmol]

Elektroid crash when I transfer file with non western character, here: '繁'.

Segmentation fault (core dumped)

I don't mind renaming files but the error should be made explicit.

[dagargo]

I've assumed you were using an Elektron device, I've replicated the error and solved it. Now, the transfer fails although the error is very generic but Elektroid doesn't crash.
Sadly, improving the message would require many changes but, at least, there is a proper error printed out to stderr.

Let me know if the fix works for you.

Regardless of this, there might be other conversion issues in the code.

Elektroid tries to handle some encoding issues transparently. However, this does not solve the more generic issues presented here.

• Typically, devices support ASCII-like alphabets AFAIK.
• Particular MIDI devices might handle characters differently. As MIDI devices do not require to be ASCII compliant, they might represent some bytes in a different way than computers do.
• Uploading an item will typically set the name as it is in the content of the file being uploaded but some filesystems will try to use the name of the file in the computer and perform some conversions. In the case of the Elektron samples, names are translated into CP1252, which is the format used internally but does not allow characters like '繁'.
• Renaming an item, depending on the connector, would apply some character conversions too as devices do not support the same set of representable characters. For instance, this.

elektroid/src/connectors/phatty.c

Line 25 in 08838f8

#define PHATTY_ALPHABET " ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyz!#$%&()*?@"

The question here is how to improve the functionality for non Latin languages. Since I'm not familiar with using an alphabet outside the ASCII-Latin one I don't know how to deal with all this and other issues might appear.

• What are the best practices?
• Can something be done to improve the user experience?

[dagargo]

Probably my explanation was a bit over the top.

Would replacing '繁' with '?' be a better choice from the user point of view? The upload would not fail but would overwrite a sample called '?'.

EDIT: I forgot to mention this is the normal behavior in the connectors and I'd rather do this.

[dagargo]

I ended up changing the implementation.

As I mentioned in my previous comment, the standard behavior is to try replacing non ASCII characters with ASCII ones.

This has the aforementioned drawback of uploading or downloading the sample 繁 as if it were named ?.

Let me know if you have any issues with this solution.

[chmol]

Hello, sorry I forgot to follow trough.

• yes, i was transferring on a digitakt.

• From a user perspective I think the renaming is the best solution. If it's not cumbersome to implement the following would improve the experience:

  • pop-up when the error occurs with the option to either stop the transfer and rename manually or automatic renaming.
  • summary of what has been automatically renamed once the transfer is done

I'll test with the problematic sample as soon as I can.

Thanks a lot.

[dagargo]

Implementing the renaming would require a few things to be properly checked and add a dialog and change some minor things. This is the reason for removing this from version 3.3.

The idea would be check if the destination device language supports the language used in the filename or if the filename can be converted.
If any of these conditions are met, then the transfer should be done without further action as it's performed now.
If not, we should proceed as explained by @chmol in the previous comment.

Edit: But it shouldn't chrash now.