DSP Robotics Support

"As I read, the memory increase reduces over time, which indicates to me that everything is just fine."

I dont think anyone that has tested this and has observed the memory leak has seen it decrease over time ?
Certainly does not do that for me or Spogg? I have literally run this for hours.
Try running "advanced envelope" or any Ruby sequencer it just keeps eating memory and does not let go of it.

Spogg´s comments.

"The Ruby one accumulated memory as I tweaked the knob up and down. It didn't ever reset (10 minutes of no action). The knob is not connected to anything so it’s purely the graphical load."
"I got the same behaviour! The memory used by Reaper increases steadily by 5.8MB/minute. No activity, no notes playing so nothing moving on the screen"


My plugin that has 3 Advanced envelopes and 3 circular Nubeat7 is unusable ..it reaches almost 2 gig before i just shut it down.

Maybe its not a problem on Win 10 ?

The volume knob that Tulamide posted was exported from 3.06 and was a problem on both my Win 7 machines but not the Win 8.
Everything I export as VST is however a problem on all my machines.
I have provided screenshots , gifs , fsm, don't know what more I can do?

I don't think this has anything to do with the ruby garbage collector being lazy.
Here's another way to look at ruby object counts.

The number of ruby objects stays constant, while the memory does steadily increase when using it with the advanced envelope schematic for example.

MyCo wrote:My assumption is like that: Ruby is VM which manages it's memory dynamically. This means it allows itself to allocate as much memory as it wants to a certain limit (depending on the free mem reported by the OS, but max. 3GB as that's the 32Bit limit). When the OS reports "hey I have ~100GB of free mem", then Ruby just doesn't bother and allocates more memory when need, without ever freeing it. On a low memory system, Ruby might free the memory after the garbage collector ran (which is slow!). On a high memory system ruby runs the garbage collector but keeps the memory allocated so it can use it whenever it's needed.

To be clear, the memory is allocated... but internally not all of it is used.

However there is one odd thing to it: It happens only in the VST and not in FS, and I've no clue why... There is no different setup for the Ruby Interpreter in the VST. It might have something to do with the clock rate that is used to "contact" the ruby interpreter. So the interpreter is a bit more "busy" and therefor doesn't clean up as thoroughly?

Your assumption has a flaw! If we ignore the very special issues of lalalandsynth for a second, then we have the situation that the issue only appears with FS 3.0.8.1, and not with 3.0.6. It was confirmed by Adam, Spogg and myself. A more than clear indication that there was a change that introduced the issue, especially since it only happens with exports.

While waiting for a fix I suppose to use 3.0.6.

TheOm wrote:I don't think this has anything to do with the ruby garbage collector being lazy.
Here's another way to look at ruby object counts.

ruby objects.fsm

The number of ruby objects stays constant, while the memory does steadily increase when using it with the advanced envelope schematic for example.

I'm not sure I can follow you. I opened your fsm, added an advanced envelope and turned the knobs like crazy. The amount of memory stays the same, while the number of objects goes to very high values (>200, just references I assume?). Letting go off knob turning, the number of objects goes down until normal again. This is with 3.0.6

Yes that's exactly the point I was trying to make (I'm using 3.8.1).
The Object counts do not increase (averaged over a longer amount of time), that means there is no "Ruby object leak" like holding on to references that you don't need anymore and such things.
and you can clearly see the garbage collector doing its job.

That means the leak is caused by something else, maybe in the Gdi+ wrapper functions.

Now I understand. Took me a while. Yes, that's reasonable. And the GDI+ "API" is another candidate for inspection, for sure.

Don't have 3.0.6 and neither do I have the code changes before 3.0.8, so I have no idea what changed. I can't spot anything in the changelog (http://www.dsprobotics.com/versions.html) either.

Anyone tested 3.0.7 ?

OK guys... might have found something. Please try this in 3.0.8.1

Go to Options -> Advanced and set "Ruby Timeout" to -8000 (default should be 8000), it is important for this test that the number is negative

Then export as VST again.

MyCo wrote:OK guys... might have found something. Please try this in 3.0.8.1

Go to Options -> Advanced and set "Ruby Timeout" to -8000 (default should be 8000), it is important for this test that the number is negative

Then export as VST again.

YAY!! FIXED!!!

No leakage with the Ruby knob, just fluctuation as with the SM one.
Re-exported the Harvester and the memory is completely stable apart from minor fluctuations up AND down. Plus everything I tested (not so much) seemed to work ok. Just as an aside my original setting was at 10,000 and I don't know why it wasn't at the default of 8000 but I wouldn't have changed it unless suggested by someone.

So what changed to make it necessary to have a negative number? This is counter-intuitive so did an error creep in and will it be fixed in 3.09? Also what are the implications for making this config change? Could it break something?
I guess I'll have to re-export ALL of my projects if this is the final fix, but never mind.

I'm very grateful to you for finding this and also very impressed!

Cheers

Spogg

woohoo, cant wait to try this out !