Support Micro Freak Projects

[sturd]

When downloading presets for the Micro Freak from the web, they tend to be supplied as .mfprojz files—zip files containing sets of serialised preset files.

I have been exploring the codebase, and looking for a way to treat these zip files as if they're a directory in the local browser, so that individual presets could be selected and uploaded to the device.

The workaround is to manually unzip the downloaded .mfprojz file, mass-rename the extracted presets from .mbp to .mfp and upload via Elektroid, but it would be much nicer to do within the UI itself.

[dagargo]

While handling mfprojz files would be quite difficult because of the internal API limitations, transferring mbp files should be easy. In fact, I thought I already implemented this.

Let me take a look at it this evening and I'll come back to you.

[dagargo]

Transference of mbp files is currently implemented but, as you said, needs renaming.

There is a very simple workaround which is adding the mbp extension to the list of allowed extensions for the MicroFreak presets (preset filesystem).

This is the patch.

git diff
diff --git a/src/connectors/microfreak.c b/src/connectors/microfreak.c
index 729d5e33..8b065358 100644
--- a/src/connectors/microfreak.c
+++ b/src/connectors/microfreak.c
@@ -55,6 +55,7 @@
 #define MICROFREAK_DEFAULT_CHAR '.'
 
 #define MICROFREAK_PPRESET_EXT "mfp"
+#define MICROFREAK_PPRESET_EXT_2 "mbp"
 #define MICROFREAK_ZPRESET_EXT "mfpz"
 
 #define MICROFREAK_WAVETABLE_EMPTY 0x08
@@ -712,6 +713,7 @@ microfreak_preset_get_exts (struct backend *backend,
                            const struct fs_operations *ops)
 {
   GSList *exts = g_slist_append (NULL, strdup (MICROFREAK_PPRESET_EXT));
+  exts = g_slist_append (NULL, strdup (MICROFREAK_PPRESET_EXT_2));
   return g_slist_append (exts, strdup (MICROFREAK_ZPRESET_EXT));
 }

Let's keep in mind that the browser shows the file name and Arturia MIDI Control Center shows the inner name used in the presets.

There is another option though.

A couple of items could be added in the application menu for uploading and downloading full projects. The problem with this is the time required to implement it. And there is an issue too.
In Arturia MIDI Control Center presets are selected before uploading. Elektroid won't support this without many internal changes so only full uploading would be supported which would mean that the previous presets would be deleted.

BTW, I wanted to release version 3.1 during the following weekend and I'd prefer not to delay this any more.

Possibly, there are other alternatives but given the circumstances I'd go with the first one.

What are your thoughts on this? Is this enough for you?

[sturd]

A patch is great, thank you very much! I will get that applied to my local copy.

I agree with what you're saying about internal changes being needed to support browsing of, and selecting presets from, .mfprojz files; and it would be a clumsy feature if a user was forced to blindly drag-and-drop, or click upload, the entire project file into the preset bank, clobbering other presets that they may have wanted to be kept intact.

I could see from other discussions that you were aiming to release a new version. Would you be happy to leave the issue open for further discussion on a more permanent solution to this, following the release of 3.1 (also, maybe, after your push to migrate to GTK4)?

[dagargo]

Applying that patch before the 3.1 release won't be a problem and will solve this scenario partially.
I haven't pushed that patch today due to a lack of time to test it thoroughly but I can do it before the release or delay the release a few days if needed. Also, the ppreset filesystem will benefit from this too but I'm not sure if adding this extension there is a good idea.

Test it and report it if you feel like it. It worked for me but...

However, as you suggested, I'll leave this open for further discussion and move it to the 3.2 milestone.

Although 3.2 version is gonna be mainly a GTK 4 port, patches for connectors will be welcome as long as didn't need API changes.

[sturd]

Thank you - the patch worked so my installed version of Elektroid now allows upload of .mpb files.

I would keep the patch out of your master branch if it will add to the test effort and potentially hold the release back.

Thanks for your help on that though; and thanks for freeing my MicroFreak from having to boot Windows for modifying my patch library! I'll contact you again in this thread for moving forward in the future. Good luck with the release.

[dagargo]

I've pushed the aforementioned changes in 84d510a to show mbp files in the local browser.

As agreed, I'm moving this to the 3.2 milestone.

[dagargo]

Just some information about the local browser.

The local filesystem has 2 different modes. This are specified in https://github.com/dagargo/elektroid/blob/a8162d52511812804b1a4949f01da529ef56c134/src/local.c and controlled by the different filesystems with the option FS_OPTION_SAMPLE_EDITOR which is ultimately updated here.

elektroid/src/elektroid.c

Lines 2023 to 2033 in a8162d5

	editor_visible = remote_browser.fs_ops->options & FS_OPTION_SAMPLE_EDITOR ?
	TRUE : FALSE;
	if (editor_visible)
	{
	local_browser.fs_ops = &FS_LOCAL_SAMPLE_OPERATIONS;
	}
	else
	{
	local_browser.fs_ops = &FS_LOCAL_GENERIC_OPERATIONS;
	editor_reset (&editor, NULL);

Perhaps, and this is just an idea, instead of having this, filesystems could define their own filesystems for the local browser instead of using a flag to control this.

It would be quite a lot of work but a new project filesystem could be possible.