dagargo
Microfreak goes beyond sample boundaries
OS: Debian Testing elektroid version: built from git source on 2024-06-05
I just uploaded various samples onto my Microfreak. Ran into the issue that it seems not to know where these samples stop.
Expected behaviour: The uploaded samples can be played from start to finish individually with the Microfreak Samples oscilator parameters Start=0 Length=100 Loop=Off and no Modulation that would switch between samples.
Real behaviour: When playing a sample with the above parameters, the one(s) after it start playing after it finished (depending on length)
(Also: huge thanks for tackling the Microfreak!!)
Thanks for reporting this.
By any chance, do you know if there is a limit in the sample length in the documentation or imposed by any Arturia software? Forcing it should just work bu haven't found anything.
This is probably the same issues I was commenting in #123.
By the way, I have some commits that want to push during the weekend regarding the microfreak connector.
The Microfreak manual (current version, p. 112) says individual samples can be up to 24 seconds long and anything upwards of that will get cut.
Additional info from my end: Samples that I upload from my Debian machine show up as having 0MB size with elektroid-cli microfreak-sample-ls 1:/. A sample I sent yesterday from my Laptop (running Arch) using the GUI was listed with a nonzero file size however and also didn't show the bleeding-over behaviour. I have no idea why, though.
It's true. Now I remember!
I've checked out a few things.
But first, some calculations based on constants we know assuming the 24 s maximum sample time.
Maximum frames: 32000 frames/s * 24 s = 768000 frames
Maximum bytes: 768000 frames * 2 B/frame = 1536000
Maximum batches: 1536000 B / 4096 B/batch = 375
We could define a new constant MICROFREAK_MAX_BATCHES based on that and then use it here to impose this upper bound.
https://github.com/dagargo/elektroid/blob/1c252667d0ebeaf9766d2b6bdae8fec35751caae/src/connectors/microfreak.c#L1088-L1089
However, are you having trouble when uploading such long samples or is the problem appearing with shorter samples? Are 24 s samples working well with Arturia software? IIRC I ended up not implementing the upper bound because I was having issues with shorter samples.
I haven't tried out samples anywhere near the maximum length. I'd need to check for details on my desktop PC again, but roughly speaking the ones I've tried were in the range of 0.1s to 5s. The short ones would definitely blend over into those after them, and one longer one stopped right within.
Additional observations:
- Even samples that are "deleted" might play after the ones that are not. I suppose that's why you wrote both a rm and a clear function?
- The described behaviour doesn't depend on the samples being stored in sequential slot IDs but instead on sequential uploads. If I upload a sample in slot 4, then in slot 5, then in slot 3, then play order is also 4→5→3.
The issues you mention are quite similar to the ones I experienced. All my tests were below the 24 s limit.
Perhaps, the issue is in the deletion of previously stored sample. Were you overwriting samples or using empty slots?
I'll check everything during the weekend and come back with some answers.
Regarding the rm and the clear functions, the former is supposed to remove the entry and the latter is meant to initialize the slot.
Elektroid is capable of using filesystems with a hierarchy of files and directories, which can store an undetermined amount of files; but also, lists of elements (presets or the like). There are some differences among them and one of those are these calls.
Excuse me for taking so long to answer.
I checked everything a couple of weeks ago and the MIDI messages between Elektroid and the MicroFreak were similar to the ones between Arturia MIDI Control center and the device. But not quite it seems.
Lately, I've been polishing some thing here and there and doing some deep refactoring as I intend to document the API for others to implement their devices for version 3.2 but I wanted to do it now. All this is now completed.
Anyway, just wanted to say I'm still working on this and try to check everything again during this month.
I've pushed some commits to the master branch but also pushed some commits to the fix-microfreak-sample-upload branch.
This branch contains a fix for the sample upload. Now, there is a new phase after the upload that seems to do something although it makes no sense to me. This section is sometimes unneeded but the code handles this case.
So far, I haven't been able to replicate the issue with this.
I've just deleted all the samples and started adding new ones and everything seems to work well.
(I've only found a small issue when deleting a slot and the following one is in use when uploading a new sample bigger than the previous one in that slot. Assuming the MicroFreak stores the samples in contiguous blocks, this makes sense and I don't think it's possible to address this.)
@the-all, could you test if you're still having issues with the new branch?
BTW, sample renaming has been added.
Some improvements have been added as well as some documentation.
https://github.com/dagargo/elektroid/blob/809e3fadfdbf1cf11c5bb7ee3ceab6fb36b54942/src/connectors/microfreak.h#L49-L59
Everything seems to work quite well.
The only remaining thing is the defragmentation. If the sample addressing space is too fragmented, Arturia MIDI Control Center will show a message indicating that although there is enough space a sample could not be uploaded due to fragmentation and offers the option to run a defragmentation process.
Along with some improvements, I've pushed the code to run the defragmentation process.
Basically, it is something that runs in the MicroFreak and only a single -and quite short- message is sent. A response is received whenever the process terminates.
A similar dialog to the one above is shown.
After many attempts, the implementation of sample renaming, which is not part of Arturia MIDI Control Center functionalities, needs to be removed as it does something to the sample. It seems to erase the first block of samples but since there is no way to extract the content of a stored sample I'm not completely sure of what's going on. The silence can be heard sometimes but an audio recording and visual comparison has been needed.
The same approach was used for wavetables and presets and seems to work.
Other than this, I consider that there are no other issues regarding the microfreak connector, the branch can be merged and the issue closed.
Hey there! Sorry I didn't get back to you about this, had other stuff going on… Just tested this out and the bug seems to be fixed on my end as well!
Then everything's is confirmed to work well. That's really great!
Thanks for testing it!
It's been a pity having to remove the sample renaming but it was a total hack.