What's new

Hit "Memory Exhausted"

merlinhimself

Senior Member
My on init was getting pretty lengthy and I hit the memory exhausted error, I still have some ways to go but if anyone has any tips on avoiding this please share! I moved all my "move_control_px" to on persistence which cleared up a good deal of room but I'm still worried I'll hit that error again before I finish :| is it a limit on lines or characters in the init or what? Move control px doesn't really take up any memory it's just a command.
 
Use arrays for control parameters then loop through them to set them up. This saves a lot. Another thing you could do is use Creator Tools for defining the whole GUI, then that is completely separated in its own file that you import.
 
Use arrays for control parameters then loop through them to set them up. This saves a lot. Another thing you could do is use Creator Tools for defining the whole GUI, then that is completely separated in its own file that you import.
I'm well into design so Creator Tools is ruled out for this instrument haha. I have found that spaces do matter in the ICB, I typically add spaces here and there to seperate chunks to its more readable, but will do a pass to try and take them out where I can. One question I do have though, I'm using a ton of "math variables", LIKE A TON, because a lot of math is happening for different things at once so I had to separate it all. Is there any downside to using an array for that type of stuff? I setup for one function using an array for the math variables and it seems to be ok, but wasnt sure if overall using arrays for that type of stuff takes more time or has some hidden con? I was able to turn 100 variables into 4[25] arrays which cleared up space in my ICB.
 
I'm using a ton of "math variables", LIKE A TON, because a lot of math is happening for different things at once

Is this "at once" involving wait() or not? Because if it isn't, you need to be aware that callbacks are always executed serially, even if they seem to happen "at the same time" (they never do in real life). So you can use i.e. $i as your global loop counter pretty much everywhere, unless there's some wait() involved. If you need threadsafe variables for these cases, use taskfuncs.

I don't believe you realistically need hundreds of temporary variables to do math, unless (indeed) you're building a time machine. :grin: Maybe a dozen or two, but A TON seems overkill to me. You can reuse a few temporary variables for calculations where wait() is not involved, for sure. That alone should help a lot.
 
Last edited:
Is this "at once" involving wait() or not? Because if it isn't, you need to be aware that callbacks are always executed serially, even if they seem to happen "at the same time" (they never do in real life). So you can use i.e. $i as your global loop counter pretty much everywhere, unless there's some wait() involved. If you need threadsafe variables for these cases, use taskfuncs.

I don't believe you realistically need hundreds of temporary variables to do math, unless (indeed) you're building a time machine. :grin: Maybe a dozen or two, but A TON seems overkill to me. You can reuse a few temporary variables for calculations where wait() is not involved, for sure. That alone should help a lot.
In it I don't have any wait statements for these functions, but when I first started building it I noticed I was getting a lot of mixed signals so I started giving each their own variable which stopped it from happening.
 
Ah, so you went overboard with it rather than only adding new variables when you notice something weird happening? Doing stuff like that automatically by default is kinda what leads to... spaghetti :)
 
Ah, so you went overboard with it rather than only adding new variables when you notice something weird happening? Doing stuff like that automatically by default is kinda what leads to... spaghetti :)
Each function may or may not happen, it's all user controlled so I didn't want to leave it up to chance that the right combination of functions would break the instrument or not. I definitely went overboard for sure, but it was happening pretty frequently when those variables were being used in more than one function being called.
 
That still makes no sense if there's no wait() involved, variables don't get overwritten, they exactly have lifetime of only the callback they were called in.
 
That still makes no sense if there's no wait() involved, variables don't get overwritten, they exactly have lifetime of only the callback they were called in.
Yeah I double checked everything to see if maybe I had a wait() somewhere along the line but there weren't any
 
Weird. I never had any such issues reusing variables. But, hard to say anything for sure without going through your whole code. I bet you're doing some careless things in some places :)
 
Weird. I never had any such issues reusing variables. But, hard to say anything for sure without going through your whole code. I bet you're doing some careless things in some places :)
Most likely! Haha. I'll keep digging through it to see what may be causing it.
 
Weird. I never had any such issues reusing variables. But, hard to say anything for sure without going through your whole code. I bet you're doing some careless things in some places :)
made a small discovery, found that the variables are getting mixed up when theyre working for the reverb's internal dry/wet parameters along with anything else. All the other fx parameters seem to work ok with the same variable, but for some reason when theyre dealing with dry/wet parameters on reverb, or filter, or delay, thats when some mischief happens.
 
Weird. I never had any such issues reusing variables. But, hard to say anything for sure without going through your whole code. I bet you're doing some careless things in some places :)
Figured it out! Something silly I totally missed. Now once I build up the courage to replace my tons of variables throughout the script with just a handful, Ill have a nice efficient and clean code : )
 
Top Bottom