LumaConfig — Max patch keeps crashing, maybe caused by Uzi or qmetro
Hi, this is Valky River. I recently made this patch (LumaConfig) for generating layouts for the Lumatone keyboard. However, I ran into an issue — it crashes a lot. Whenever I load a file with it, sometimes it works fine, and other times it crashes. Does any of you know why this is happening?
I feel like it's either the Uzi or the qmetro causing this, but I couldn't find a way around it.
(Note: after downloading, change the file extension of the file from .maxpat to .zip and then unzip to reveal the actual .maxpat files)
Wow that's big, I'm not even trying to understand your patch!
But I found a few things:
Do not [deferlow] the output of a [Uzi], it would just mess up the order of operations
No need to use [Uzi] in conjunction with [counter], just use the rightmost outlet of [Uzi] with a [- 1] instead
Replace all of your [qmetro 2] by [Uzi]
Use [coll] to store data instead of [umenu] if they aren't meant to be selected in a menu by a user
That part in the bottom right with the SAV button and a [delay 50] is suspicious. I would simplify things like so:
...but with a [coll] instead of the [umenu].
These are just assumptions and guesses, I didn't try to actually use your patch or make it crash.
Previously, this patch contained a lot more [Uzi]s, which I replaced with [qmetro] because it was causing too many crashes. Even with the replacement, the patch still had a tendency to crash, especially when uploading a file, because in this case, the [Uzi 56] can't be replaced with a [qmetro] without messing up the states of the bpatchers.
By the way, the [delay 50] connected to [r savinglayout] is just there to hide a panel after the process of saving a file is completed.
If you get crashes with [Uzi] then you probably did something wrong in the timing / order of operations somewhere.
The [deferlow] just after [Uzi] is a good example of that. At some point it maybe solved an issue, but in the end it messes everything up as the patch gets more complex.
But in the end my point is that using [coll] to store your data, you don't event need [Uzi] or [qmetro] at all, since you can just dump all data in it, and you have way more options to edit its content. dump is also available for [umenu] that you use, but as I stated above, [umenu] is really more suited for user interaction, not storing data. You can also export/import the content of a [coll] directly, without having to mess with [text] as you seem to do for [umenu].
Also, not sure if it can help, but it's worth trying: disable Scheduler in Audio interupt, and make sure to [defer] any message that is supposed to write/read to/from the disk.
I can't really give more precise indications since your patch is so big it would take me at least an hour or more to make a proper diagnosis and suggest more suited solutions. What you can do to help us help you (and help yourself by the way) is to try to narrow down the problem by removing parts of the patch one by one and see if it still crashes. Or do the opposite: rebuild your patch from scratch by adding elements of the full patch one by one, and see when problems arise. If you do this carefully you will manage to isolate the issue and probably solve it by yourself, or come here with a more precise question.
I had a brief look at this.
I don't think you have clear idea about what gets executed in which order.
too many sends / receives, uncontrolled parallel processes,
repeated output of calculations due to rounding etc.
that is the problem.
If I were to fix this, I would make clear structure, start one thing and
proceed only when it executed.
and reduce conversions to be more efficient if they need to execute
fast.
one example among many :
@Source Audio I apologize, but I don't have an idea what you are referring to, and what you mean by a "clear structure". (Okay, I'm absolutely trash at Max.) All I know is that most of the crashes seem to come whenever a large number of processes have to come at the same time.
@TFL Also, I only tried using [deferlow] as a last-ditch effort in an attempt to reduce crash rate. It wasn't supposed to be there in the first place. And to be honest, I don't really know how [defer] and [deferlow] work. I do not have sufficient time to rebuild the patch from scratch. Also, does [dump]ing out the contents cause the same amount of queue lag as using [Uzi] or [qmetro]? Does using [coll] reduce the amount of lag by a significant amount?
EDIT: It did seem like using [coll] instead of [umenu] for the main data does reduce crash rate.