Bug when uploading samples that makes these not compatible with Elektron Transfer

[dagargo]

Looks like Elektroid sample uploads are not compatible with Elektron Transfer. I'm unsure about the time this got broken. But haven't researched much yet.

For anyone interested in the Elektron Transfer compatibility for samples, it'd be very helpful to discuss this issue here.

There is a small difference in the downloaded files when uploaded with these tools. More specifically, the looptype member of this struct is not in the right endian format. (I'm not really sure if the Transfer format follows the convention.)

elektroid/src/connectors/elektron.c

Lines 62 to 71 in 8ba2058

	struct elektron_sample_header
	{
	guint32 type;
	guint32 sample_len_bytes;
	guint32 samplerate;
	guint32 loopstart;
	guint32 loopend;
	guint32 looptype;
	guint32 padding[ELEKTRON_SAMPLE_INFO_PAD_I32_LEN];
	};

Anyway, this is not the actual issue. The issue is that the hash the devices use to use to identify samples in their CAS depends on this value so changing this value will probably break sample uploads when uploading projects and sounds.

I still need to run some tests but this doesn't look great. 😞

This is the patch that would fix the downloads in Transfer but could break projects and sounds backup.

$ git diff
diff --git a/src/connectors/elektron.c b/src/connectors/elektron.c
index 3e4f43f..f369191 100644
--- a/src/connectors/elektron.c
+++ b/src/connectors/elektron.c
@@ -57,7 +57,7 @@ static const gchar *FS_TYPE_NAMES[] = { "+Drive", "RAM" };
 #define ELEKTRON_NAME_MAX_LEN 32
 
 #define ELEKTRON_SAMPLE_INFO_PAD_I32_LEN 10
-#define ELEKTRON_LOOP_TYPE 0x7f
+#define ELEKTRON_LOOP_TYPE 0x7f000000
 
 struct elektron_sample_header
 {

[dagargo]

I'm working on the branch https://github.com/dagargo/elektroid/tree/101_sample_upload_bug.

[dagargo]

Looks like the issue is less problematic than I anticipated because while samples themselves can not be downloaded with Transfer, projects are downloaded with their associated samples without issues. Same is true for sounds.

This is good news. 🌈

[dagargo]

In the case that someone would want to download the samples with Transfer, re-uploading the samples to the same path will change the hash used in the CAS and will unlink projects and sounds with their associated samples. A better way to proceed would be to open the project or sound, re-upload the associated samples, re-associate the samples and then save the project or sound. Very tedious and error-prone.

Still, if the goal is just to download a sample, there is another option. If samples are re-uploaded to a different path, downloading these new samples will work with Transfer and the projects and sounds will still be associated with their original samples. After, the copied sample could be deleted.

I'm very very sorry. 😞

[dagargo]

Since projects and sounds download fine even if the internal hash calculation doesn't match, perhaps the best approach will be to do the following:

1. Back up every sound and project from Transfer.
2. Re-upload these from Transfer.
3. Back-up all the samples.
4. Re-upload all the samples.

If Transfer fixes the hash when re-uploading, this will work. But I haven't tried this.

[dagargo]

I've decide to fix this so using Elektroid is compatible with Transfer.

For anyone using both Elektroid and Transfer, be aware of the aforementioned possible issues.

Fixed in f8a0fee.