Another round of bug fixes, including the last “big” one for MM (crashing after unloading a plugin, then re-loading a different version of it)
Also fixed an issue with the Options menu not being clickable, when GUI processing takes too long. I added a menu option to change the graphic display update rate, and also just disable drawing graphic screens entirely. This is akin to the “Show/hide cables” and “Show/hide maps” settings in the Module View and Patch View pages.
Also, from now on “Autoload Plugins” is known as “Preload Plugins”. Discussion is here:
What’s changed since v2.0.0-dev-13.8
Graphic display settings: Hide/show graphic screens and throttle update rate on ModuleView and PatchView pages
Fix crash when unloading a plugin, then loading a different version of same plugin
Fix crash when file directory listing in file browser has long file names > 64chars
Fix audio not always fading up when loading a patch (rare bug, not reported)
Rename “Autoload” to “Preload”
Fix display of Preload and Load All buttons on Plugin Tab (do not show a button if clicking it would have no effect because no plugins are found or loaded)
Yes, very happy with the loading speed now. It feels complete though I had a new patch freeze on me. I did not save it earlier so nothing to report for troubleshooting purposes.
My only issue with Meta so far is that sometimes when you jump between knob pages the knobs accidentally jumps to last visited page value. The workaround for me, only use one knob page! Less is more! I’m on the latest build.
Hm, not sure. I haven’t change anything in those setting. I can see a ”line” for position, but then a few of the knobs moves accidentally. To the position on the physical unit if I come from another knob page.
@danngreen just tested 13.9 and am getting crashes again when running through a set of patches (via usb). these use latest canard, mshack, bog, and fundatmental. i have the screen timeout set to 30 sec. i have draw screens turned off. system 48/512/4(or). i can usually get up to patch 4 or 5 (starting from 1) and then the screen hangs:
steps:
load 1st patch (takes about 50 seconds after you hit play)
load+play 2nd patch in series
load+plau 3rd, and so on
observe it will crash around the 4th or 5th patch
will pm you a link with the ymls + .wav files
let me know if there’s any more info i can provide.
Ok, I’ll try it out. But I went through the Canard code recently and there are some bugs in that module that would cause a lock-up. So my hunch is that.
Hmm… well, I got all the patches to load with no crashing, but I’m testing on v2.0-rc1 not on dev-13.9. Bidoo is v1.0.5, Bog and Fundamental are v2.0.7-rc2. mscHack v1.0.1
I tried it with draw screens enabled by accident at first, got to patch 08 and then realized my mistake and repeated from 01 with draw screens off.
The only difference I see is maybe my USB drive is newer/faster, as it loads each patch in around 35 seconds. Though that really shouldn’t make it crash (even a disk error should just fail, not crash).
The nature of the bug I saw in Bidoo is that it might randomly lock up if the timing is wrong (e.g. the GUI thread and audio thread might lock each other if they are called at the wrong moments). So it could be related.
Try v2.0-rc1 and see if somehow that fixes it (though I didn’t change much!)?
Update: I noticed you had all knobs down and only Out 1 and 2 patched. I repeated it again with that configuration, and got to patch 08 before I stopped.
just tried it with 2.0-rc1 as well as all the latest plugins from the download page. sadly got a crash on the 2nd yml set01-02, then on a 2nd run through it crashed on the 4th yml set01-04.
are there any other settings i should try?
also curious what usb drive you’re using?
mine is an exFat, 128gb(the one ive been using since i got the mm)… i also tried with a separate 32gb fat (the one in the video above). same results with both.
going to try with the sdc to see if i get the same result
update: same issue with sdc, crashed trying to load set01-05
update2: tried on the 2nd mm (i keep in storage until live performances) and still same issue, crashed when loading the 2nd yml (1st one loaded ok) via the usb drive
Hmm… I matched your audio preferences (48k/512/4). Also I only loaded the plugins you mentioned. I can try with a different USB drive tomorrow.
The only thing is that I used firmware built on my machine, instead of the one you would download. I can download and and install it. Unfortunately if it crashes with that version, then my debugger won’t be able to tell me as much information, but at least we’ll be able to know what’s causing the difference.
thanks for the link! i might have to get one of these as the 35 seconds load time you mentioned, is quite a decent enough different from the 50seconds time im experiencing with these usb 3.0 thumb drives.
of course im still getting the crashes with the sdc… so i suppose that rules out that this is a usb drive problem?
and just to double confirm: you were definitely using only the 15mb 48khz/16bit (all 80seconds long) samples that were in the .rar i pm’d you yesterday?
i figured it was a memory thing, though it’s interesting that you were able to get to 12 from 02… i’ve only started at 01, and the highest i got to was 04, it crashed during load of 05. i even tried loading a completely blank ‘init’ patch between loading each of these ram heavy ones, maybe to see if it made sense to ‘unload/flush’ ram first… and yet still got the crashes regardless
So, there are two things here: one is that sometimes it takes about 55 seconds (~9 sec per canard) and sometimes it takes 35 seconds (~5.5 sec per canard).
The other thing is that sometimes canard crashes when loading the samples.
For the first one, the slower loading happens when canard is running while it’s loading. I mentioned in another thread (Options menu not showing up - #12 by danngreen) how it tries to create new async threads repeatedly while it waits for the first one to load. There might be other things its doing while loading that are causing it to slow down. So that should be fixed in the Canard code. Probably we can have it load the initial file in the normal thread (no Async thread) and that will solve it.
I don’t know yet why it crashes sometimes, but I still suspect that it’s something to do with the fact the Async threads launching outside of the audio context.
What I’ll do is put a little guard in the firmware repo to stall the audio from loading until all async threads have been launched (which is what was happening on my locally built version – why it was loading in 35 seconds because I have console debug logging enabled while caused the short delay before audio started). It’s just a band-aid, though.
I think the real solution is I need to do a better job documenting usage of AsyncThreads.
I started refactoring Canard, to make it more safe between the GUI and audio threads, I’ll continue there.
Also the STSP uses AsyncThreads to stream from disk to the buffer, so I could just finish that!
thank for the detailed report dan! super glad to hear its at least pin-pointable/fixable. i look fwd to guinea pigging any new firms/plugin versions, whathaveyou.
and re: stsp (w disk read functionality!)- exciting to hear thats still on its way. i can safely say for most all mm(and vcv) users, we’ll be most chuffed whenever that ends up becoming good and ready to play w!
just tried out rc2, i noticed the faster 35s load times, nice! but unfortunately still crashing when loading the patches. my first run through, it froze when trying to load 03. the second run it froze when attempting to load 05.
I’m on the latest build.