2.03
load a patch with only Fundamental Wavetable VCO. In VCO change the table sample size to 2048. Load in most Wavetables stored in SD card cause the MM to crash.
I just tried loading a wav file from SD Card, and didn’t get a crash. Can you share a particular wav file that makes it crash?
I’m unable to share .wav files in the reply.
I just noticed that this particular .wav file is 2.1MB. Is there a size limit for wavetables?
There’s no file size limit as far as the MetaModule is concerned, but the Fundamental WTVCO module seems to have a limit of 1 million samples built into it. So a 2.1MB file could exceed that depending on the sample format. I wouldn’t think it’s designed to crash with big files, so there might be a bug in there still.
I’ll try some large files when I have a chance and see if I can make it crash too.
I am able to load that WAv in VCV rack into wavetableVCO
Same conundrum here - can’t get more than one WT VCO to load custom table. Needing some crispy dub stabs but don’t see a wavetable with scanning ability for MM.
Neither WT VCO nor sickozell wavetabler work - tried both 44khz and 48khz.
OK, I got it to freeze with a file. I’ll figure out why…
So I’m not sure this solves everything, but there’s a potential race condition in the original Fundamental VCV code, which is addressed on VCV with a short delay to try to “outrace” the DSP thread when loading a new sample. The timing of this would not carry over to the MetaModule, so instead I implemented an atomic flag to keep the threads in sync.
It seems to load the files that were crashing it now? But I had to try a lot of files before I got it to crash before this fix, so I’m not 100% sure this was the only issue.
If anyone who’s having issues wants to try this out:
Fundamental plugin: https://github.com/4ms/metamodule-plugin-examples/releases/download/Fundamental-v2.0.10/Fundamental-v2.0.10.mmplugin
There is a known issue that loading a patch file will not load the sample file (the filename will be displayed, but the content will be the default wavetable). I can fix this in a later release-- it’s because the original module stores the .wav file in the patch file, but this is discouraged on the MM in order to keep patch files small and wifi-friendly.
Anyways, that’s a separate thing…
Yes that would be awesome to get fixed. Thanks.
mine still freezes in 2.05 rc3 when I loaded the Serum wavetable Analog/MB Saw.wav in 2048 wave points
Ah, ok I had only been trying 1024 points. Yes 2048 points kills it with an out of memory bug.
Try this version:
https://github.com/4ms/metamodule-plugin-examples/releases/download/Fundamental-v2.0.11/Fundamental-v2.0.11.mmplugin
So what was happening is when you load a wavetable, say MB Saw which is 2MB of samples, that is then interpolated by a factor of 8 and then copied to all 10 octaves. So the 2MB becomes 160MB. The total memory available to a patch on the MM is under 300MB, so you can see how it’s easy to run out of memory with even a wavetable that’s 2MB.
What the fix in v2.0.11 does is to set an upper limit on the resulting size of the tables, to 80MB. So if you open a 2MB file then it will reduce the quality such that the total memory is under 80MB.
You still can run out of memory this way, but at least you have a better chance.
A more long-term solution involves stopping the patch and notifying the user when we run out of memory, and then modules like WTVCO would need to add a setting that lets you select the quality factor or the maximum memory usage. That way if you had a simple patch with one WTVCO you could set quality to maximum, but if you had 8 x WTVCOs you could drop quality based on your wavetable size.
Very interesting - so expansion of the waves via interpolation explains the load times. Hoping for this one, especially for the possibility of running 6 for a chord. Would be game changing.