Closed marco-polo-github closed 1 year ago
I noticed this too but I had no confirmation till now.
I didn't really research much because it's failing as well with Elektron Transfer. The issue is in the MIDI SysEx messages sent by the device. For some reason there are some zeroes in between the message bytes and these cause Elektroid to believe the result is a directory so it falls in a loop.
I'll open a ticket to Elektron and report back here.
But Elektroid should definitely not crash so I'll try to fix it. I haven't tried yet because I didn't want to go back to the previous version to get the working messages.
Edit: After taking a deeper look, the messages look right. Crossed out misleading information.
Looks like the errors on Transfer is unrelated to this.
I think the underlying cause is a bug in the SysEx message response when reading a directory that doesn't exists. Before 1.50, there was no content; but now it replies with the content of another directory, so Elektroid believes there is something there. (This is used when trying to determine if a path points to a file or a directory.)
I'm currently looking at a solution to avoid the crash.
Just another proof on the directory bug direction. The CLI doesn't perform additional checks. It just tries to download from the provided path and just works.
$ elektroid-cli elektron-sample-dl "1:/Elektron SP/Aotearoa/Purerehua-MM"
$ ls -l Purerehua-MM.wav
-rw-r--r-- 1 user user 566288 mar 28 14:47 Purerehua-MM.wav
Transfer downloads fail for a totally different reason. See #101.
I also thought the directory rights or something is wrong during the download. But also a single sample transfer failed on my setup. I will update the current versions here today afternoon and try it again, also with the recent Elektron Transfer. Which IDE setup + tools do you use to debug your code? vscode?
When I was investigating this issue I found that the reason for the crashing was a misunderstanding of the PATH_MAX
constant. I thought it was the maximum allowed length of a system path but this is not true.
I decided to fix this limitation before trying to fix the directory issue and I've already fixed it but I need to test it before pushing the code.
With this fixed, Elektroid doesn't crash but still falls in a loop due to the alleged directory bug. (Still to be confirmed by Elektron.)
But also a single sample transfer failed on my setup.
The GUI will always fail but I think the CLI will always succeed if the path points to a sample. Or does it fail the CLI for you? If so, run elektroid-cli
with -vv
and post here the output.
Which IDE setup + tools do you use to debug your code?
I use the Atom editor and debug with GDB.
What I mean by "directoy bug" is that the Digitakt replies to a non existing directory listing with a non empty response, which make Elektroid believe that path is a directory, when it really isn't.
Elektroid contains some integration tests that can be run this way. This was working with 1.40B.
$ TEST_DEVICE=0 TEST_CONNECTOR_FILESYSTEM=elektron_sample make check
Take a look to the README.md
for more information about this.
This is my commit id: commit 8ba205896d1a847101cd07788d2b5e15e285f964 (HEAD -> master, origin/master, origin/HEAD) so the most recent.
Here are some outputs:
> elektroid-cli ld
0: hw:1,0,0 hw:1,0,0: Scarlett 18i8 USB, Scarlett 18i8 USB MIDI 1
1: hw:3,0,0 hw:3,0,0: Elektron Digitakt, Elektron Digitakt MIDI 1
> elektroid-cli info 1
Elektron Digitakt; version: 1.50; description: Digitakt; connector: elektron; filesystems: sample,data,project,sound
> elektroid-cli df 1
Storage Size Used Available Use%
+Drive 959.50MiB 412.81MiB 546.69MiB 43.02%
RAM 64.00MiB 7.34MiB 56.66MiB 11.47%
> elektroid-cli elektron-sample-dl "1:/TwinPeaks/BASS_C3"
> ls BASS_C3.wav
BASS_C3.wav
Command line download seems to work as shown above. What I also experienced when I call the electron-cli is, that the play and stop is set at the same time when the command is executed. Also trying the sample download on Elektroid, changed to to (play+stop=pause right?) So it is changing this default state.
This is the log output:
What I also experienced when I call the electron-cli is, that the play and stop is set at the same time when the command is executed.
The left side of Elektroid (GUI) can detect changes in the currently open directory and will reload itself automatically in this case. If a sample is playing when it reloads, the sample will stop playing and will be unselected before reloading the content. After reloading, no sample will be selected.
It just behaves as if the user had clicked on the refresh button.
Also trying the sample download on Elektroid, changed to to (play+stop=pause right?) So it is changing this default state.
Not sure what you mean by that. Could you elaborate, please?
This patch proves the directory read bug. This is not a solution, just showing it for illustrative purposes..
$ git diff
diff --git a/src/elektroid.c b/src/elektroid.c
index 9d298b8..4a9531d 100644
--- a/src/elektroid.c
+++ b/src/elektroid.c
@@ -2538,8 +2538,7 @@ elektroid_add_download_task_path (const gchar * rel_path,
dst_abs_path = chain_path (dst_dir, rel_path);
//Check if the item is a dir. If error, it's not.
- if (remote_browser.fs_ops->readdir (remote_browser.backend, &iter,
- src_abs_path))
+ if (1)
{
dst_abs_dir = dirname (dst_abs_path);
if (file_matches_extensions (src_abs_path, remote_browser.extensions))
After doing some testing, I've pushed a few commits fixing the segmentation fault.
Besides, the preparation of transfers can be canceled now properly by clicking on the cancel button in the dialog.
Regarding the underlying bug, I've found a partial solution.
The issue happens because Elektroid needs to discern if a path points to a file or a directory in order to copy a single file or copy a directory recursively. Instead of trying to read the path as a directory and return depending on this (this is what fails now), we can previously check if the path points to a file (this feature was already in the code).
Still, this will fail if the path doesn't exist albeit this is something that shouldn't happen as long as the user is not working the with the sample filesystem on both the machine and Elektroid at the same time.
Pushed to branch bugfix_read_non_existing_dir.
Unsure if merging this is a good idea as I think the bug really needs to be solved in the Digitakt firmware. But this would be totally harmless if merged.
Is this working for you, @marco-polo-github?
What I also experienced when I call the electron-cli is, that the play and stop is set at the same time when the command is executed.
The left side of Elektroid (GUI) can detect changes in the currently open directory and will reload itself automatically in this case. If a sample is playing when it reloads, the sample will stop playing and will be unselected before reloading the content. After reloading, no sample will be selected.
It just behaves as if the user had clicked on the refresh button.
Also trying the sample download on Elektroid, changed to to (play+stop=pause right?) So it is changing this default state.
Not sure what you mean by that. Could you elaborate, please?
I mean on the DT device the buttons play and stop change their lightning if an action from electron-cli is executed. You can see that if you execute switch on the DT and then watch the keys when executing electron-cli or Elektronid GUI. ...just an observation...
the play and stop
Oh! I thought you were talking about the buttons in the GUI. Now I understand.
When Elektroid connects to the device it stops it. That's it. It is by design. But it is probably not needed. In fact, this is only happening with the ALSA (default) backend.
This is the related code.
I decide to stop the machines because it's a kind of a warning as transferences might impact the accuracy of the clock and playback if used intensively.
Do you consider this useful or harmful?
The branch bugfix_read_non_existing_dir works fine, it is currently downloading. It works for the folder and also for single samples. Great job!
the play and stop
Oh! I thought you were talking about the buttons in the GUI. Now I understand.
When Elektroid connects to the device it stops it. That's it. It is by design. But it is probably not needed. In fact, this is only happening with the ALSA (default) backend.
This is the related code.
I decide to stop the machines because it's a kind of a warning as transferences might impact the accuracy of the clock and playback if used intensively.
Do you consider this useful or harmful?
No, to stop makes absolutely sense. But isn't this just a pause, like a press play and again press play to pause? But for me that is fine. For the file transfer process, I wonder why Elektron is not showing anything in the display if a file operation is ongoing.
Great that it works!
I'm leaving this open and we'll wait a few days or so to see if the issue gets fixed in a new firmware. Then I'll decide about merging this or not. But, for now, this just works.
But isn't this just a pause, like a press play and again press play to pause? But for me that is fine.
Honestly I don't know.
We're just sending a stop MIDI message. See the specification for more details. Perhaps we could send the byte twice to see if there is any difference.
I see that both play and stop buttons are lit. Curious. I'll investigate this a bit.
Thanks a lot, really great job what you do with this project! I owe you another coffee / beer!
Elektron has acknowledged the bug but as it is unknown when they will release a new firmware, I think it's better to merge the branch and move on.
Merged into master.
Hello all, copying .wav samples and folders was working before I have updated to v1.50, and pulled recent git commits. I've pulled the latest updates with git, then make clean, and all the commands you describe, then recompiled again. But I am getting a segmentation fault. The wav files will not be listed for download in the progress window below in Elektroid. I have also deleted my binaries and cloned from the repo and compiled the sources again, with the same problem. I am using the recent Digitakt 1.50 firmware. To copy Projects with Elektroid works fine. Do you know what happens here? Let me know if I can provide more details.