A fresh Mint VM installation seems to work nicely with the master branch (version 2.2 but not released yet).
Did you tried version 2.1 from the tarballs? Could you try with the master branch?
Here are a few things for you to try. Post the output here. Perhaps there’s something interesting in there.
$ elektroid-cli -v ld
$ elektroid-cli -v info
$ elektroid-cli -v df
Other people have reported similar issues but I’m unsure if they are truly related. 
ok, I deinstalled the one from the tarballs and installed the one from the master branch. I tried those things, down here is the outcome, but now I think it is irrelevant because the problem was that I always have qjack open, so it was busy with it 
stupid me… anyways, the output from terminal actually did help me with some hints in finding the error. So thank you very much!!!
Solution: close jack!
a@b:~$ elektroid-cli -v
elektroid 2.1
Usage: elektroid-cli [options] command
a@b:~$ elektroid-cli -v info
DEBUG:elektroid-cli.c:647:(main): Operation: 'info'; filesystem: '' (0)
ERROR:elektroid-cli.c:257:(cli_info): Device missing
a@b:~$ elektroid-cli -v df
DEBUG:elektroid-cli.c:647:(main): Operation: 'df'; filesystem: '' (0)
ERROR:elektroid-cli.c:298:(cli_df): Device missingGreat! Nice to read that.
I didn’t add the device parameter to the commands above and hence the errors.
Now, it doesn’t matter.
Version 2.2 is just out. 
This version has so many changes and bugfixes that I lost track of all of them. Here are the most important changes.
I expect there will be no major bugs but testing everything is starting to be complicated.
Thanks to all the people contributing to the project. 
Hope you enjoy this.
Version 2.3 is just out.
It’s only a bugfix release related to compilation errors on other OS, a CZ bug, a couple of internal API improvements and some GUI tweaks.
Forget about 2.2 and enjoy 2.3.
I’ve added support for Moog Little Phatty (presets and scales) and Novation Summit (single and multi patches and tunings but not wavetables). There are a couple of loose ends that need to be addressed before the 2.4 release but both connectors are already working.
If anyone is interested, testing these would be much appreciated.
OTOH, the internal API is stable enough to add other devices. If anyone feels like implementing a connector, let me know.
I have a question about restoring projects backed up with Elektroid on digitakt.
I have just tried it, and have gotten the following error messages
ERROR:connectors/elektron.c:3210:(elektron_upload_data_prefix): Operation not permitted (Write: Permission denied)
ERROR:connectors/elektron.c:2704:(elektron_close_datum): Operation not permitted (Footer was not processed)
ERROR:connectors/package.c:621:(package_send_pkg_resources): Error while uploading payload to ‘/1’
ERROR:elektroid.c:2375:(elektroid_upload_task): Error while uploading
it seems that it tries to upload the project file to the first slot, which in my case is occupied by the write protected presets project. Is there a way to alter this behaviour in the GUI and allow the selection of the upload slot (like in the command line version of elektroid)?
also, I have a question about how the samples are handled when a project is uploaded. If I understand correctly, the project file also contains the samples that the project uses. What happens when the samples used in a project are removed from +DRIVE prior to restoring? where do the restored samples go?
I’ve just tried it and works well for me. Can you elaborate this a bit more so I can try to reproduce the error?
Nonetheless, it’s true that the behaviour is different from the slot mode. It saves the project in the next available slot.
Historically, the sample filesystem was the first one to be implemented and works exactly like a computer FS. Files are identified by a unique name inside a directory and so can by a unique path.
Sound and project FS, were developed later and are pretty similar to any other digital musical instrument in the sense that work with slots. But with some twists. One is that a slot can be empty.
I tried to took advantage of this feature back then and allowed to drop directly to the folder and use the next available slot.
Later, a standard slot mode came when implementing other FS for non Elektron devices. This way of working shows every slot and allows to drop over a concrete slot.
Long story short, perhaps changing the sound and project FS to slot mode is the way to go. Still, unsure about this. For other people reading this, what are your thoughts on this change?
Exactly. This is the content of a freshly created DT project. The samples are there.
$ unzip -l TEST.dtprj
Archive: TEST.dtprj
Length Date Time Name
--------- ---------- ----- ----
996 2023-01-13 18:27 manifest.json
37372 2023-01-13 18:27 Samples/Test/Kit_01_Hat01.wav
34376 2023-01-13 18:27 Samples/Test/Kit_01_Hat02.wav
67672 2023-01-13 18:27 Samples/Test/Kit_01_Kick.wav
67672 2023-01-13 18:27 Samples/Test/Kit_01_Snare01.wav
32982 2023-01-13 18:27 Samples/Test/Kit_01_Snare02.wav
43358 2023-01-13 18:27 Samples/Test/Kit_01_Tom01.wav
50812 2023-01-13 18:27 Samples/Test/Kit_01_Tom02.wav
22104 2023-01-13 18:27 TEST
--------- -------
357344 9 files
Samples are restored to their location when the project was saved. This can be done because the project contains the path at the saving time, along with its size and hash.
$ unzip -c TEST.dtprj manifest.json
Archive: TEST.dtprj
inflating: manifest.json
{
"FormatVersion" : "1.0",
"ProductType" : [
"12"
],
"Payload" : "TEST",
"FileType" : "Project",
"FirmwareVersion" : "1.40A",
"Samples" : [
{
"FileName" : "Samples/Test/Kit_01_Hat01.wav",
"FileSize" : 37264,
"Hash" : "10491825"
},
{
"FileName" : "Samples/Test/Kit_01_Hat02.wav",
"FileSize" : 34268,
"Hash" : "957195773"
},
{
"FileName" : "Samples/Test/Kit_01_Kick.wav",
"FileSize" : 67564,
"Hash" : "-685540211"
},
{
"FileName" : "Samples/Test/Kit_01_Snare01.wav",
"FileSize" : 67564,
"Hash" : "1743839387"
},
{
"FileName" : "Samples/Test/Kit_01_Snare02.wav",
"FileSize" : 32874,
"Hash" : "-1701008369"
},
{
"FileName" : "Samples/Test/Kit_01_Tom01.wav",
"FileSize" : 43250,
"Hash" : "-299435461"
},
{
"FileName" : "Samples/Test/Kit_01_Tom02.wav",
"FileSize" : 50704,
"Hash" : "1625978783"
}
]
}
BTW, sounds work in a similar fashion.
However, I’ve just noticed that there is a bug that causes sample files to be restored with the wav extension. I’ll take a look during the weekend but looks easy to solve.
I’ve just tried it and works well for me. Can you elaborate this a bit more so I can try to reproduce the error?
Not sure how to make this error reproducible. When I upload using the GUI this is equivalent to issuing
elektroid-cli elektron-project-ul SKETCHES.dtprj 0:/1
i.e. the GUI version of elektroid always uses slot number 1, not the first free slot. I am using elektroid 2.3 from december 4, 2022.
Could you try this with the master branch?
In my case, it behaves like elektroid-cli elektron-project-ul SKETCHES.dtprj 0:/. (No slot.)
This will use the next free slot.
it works with master branch, both GUI, and the command with 0:/.
sorry for the false alarm, I thought 2.3 was latest stable
are project backup file formats compatible between different versions of elektroid? my backups were made back when I was using 2.1, iirc, should I re-backup?
No worries.
Last released version is 2.3.
2.4 is almost ready but not there yet; hopefully during this month. This version is meant to be in Debian 12 if no bugs are found.
Project and sound backups follow the Elektron specifications which have not changed and are fully compatible among all the Elektroid and Transfer versions. At least theoretically. So you shouldn’t need to re-backup.
Just fixed in master and pushed.
I’ve checked everything against Transfer and overall looks nice but the negative hashes above. I’ll take a deeper look into that but looks like these values are not read from the file when restoring the backup so this bug might be harmless.
That hash was not used as a read value at all in Elektroid. But no idea regarding Transfer.
However, the issue was super easy to fix.
I decided to change project and sound filesystems to work with slots to make it less confusing and more useful.
Code is already pushed. With this changes, the internal testing framework can be used so more tests are now automated.
It’d be cool if anyone could give it a try.
I tried it, it works weirdly: there is no “upload selection” menu item in the right-click menu when I click on a project in the left pane (computer). Dragging projects to slots doesn’t do anything. Drag and drop from a file manager (nautilus) to a slot works, and uploads the project to the right slot.
another potentially dangerous behaviour: if you already have a project file such and such and download a project that has the same name, then it silently overwrites the file without warning. I think there should be some kind of notification.
This is by design.
In slot-mode filesystems, a destination slot is always needed so uploading without this is not allowed. After all, this is the kind of behavior we wanted to avoid in the first place, didn’t we?
Weird. It works fine on my setup.
Is the destination slot empty? If not, is it write protected? Can you provide us with the output of the elektroid -vv?
While I fully agree on this, there is a kind of an issue. As tasks are queued, the only possible way to deal with these kind of errors is by stopping processing the next tasks and asking the user about the current task issue. This way, the UI will be blocked until the user answers the modal because there can be only one modal at a time.
Is this right for you? What are your thoughts on stopping the remaining tasks?