DSP Robotics Support

Yes, I understand... but with the gui closed it should release the memory eventually ,right ?
It does not do that.

No, closing the gui does not release the memory. Memory is released when the GC got to work.

Note, I'm not saying that there are no issues. I say that there are many possible causes for the symptom. It is nearly impossible to say what it really is from a complex vst. Strip it down until there is no issue anymore. Use only one knob, make sure it is a knob that's not using Ruby. Create a VST that is not using the audio parts at all (Ruby issues would continue to show up). Etc.

I made a very simple test here.

2 VSTs, with inputs directly to outputs and an unconnected knob each. One was using a Ruby knob, one was a non-Ruby knob.

Tested in Windows 7 Reaper 32 bit so no bridging.

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.
The non-Ruby knob varied the memory a little as I tweaked but it always returned to its initial memory usage.

This is the simplest test I can think of to prove there’s a problem with the way Ruby is working inside a VST.

As an additional check, I tested my first synth, the Quilcom Adder, against the Quilcom 4EA+.
The Adder was made in Synthmaker and polished (if you can call it that) in Flowstone after I purchased it. The 4EA+ was made in Flowstone with the usual Ruby stuff inside. The Adder uses no Ruby and there is no memory leak. The 4EA+ exhibits the leak quite well.
This explains why some older plugins don’t show the problem.

This seems to be a very serious issue (especially as it affects my Harvester!) so I do hope it can be addressed in the forthcoming 3.09 release…

Cheers

Spogg

This is a solid test Spogg and should prove that there is a problem with the ruby implementation.
I was convinced when I did the stock chorus/delay but this should nail it.

I really hope this will be fixed as I am in love with FS.

Spoog,

Nice test comparison. I wonder if it will be patched and will it be free since it is a bug? A simple graphic knob should never ever spike the CPU or memory. Game engines can handle millions of polygons and textures.

Could you please test this .dll as well? I don't have any issues with it in my test configuration, which is Win 10, Reaper 64 bit, 4 GB RAM

https://www.dropbox.com/s/4aopeylr13f4tk5/test_volume_knob.dll?dl=1

tulamide wrote:Could you please test this .dll as well? I don't have any issues with it in my test configuration, which is Win 10, Reaper 64 bit, 4 GB RAM

https://www.dropbox.com/s/4aopeylr13f4tk5/test_volume_knob.dll?dl=1

I tested it and couldnt make it eat the memory, this seems to work.

Tested the volume knob in Reaper. 64 bit - 32 bit bridge. Win 7.
Eats memory over here when wiggled constantly.
Its a slow increase but there.
Tested 2 computers Win 7.

BUT...I tested the 3rd computer , Win 8 same Reaper version ...Does not happen there?


All previous testing I have done on these 3 computers , so it is not strictly a win7 issue...weird though ?

Adam - what win are you running ?

Windows 7 32 bit with Reaper:

Wiggling tulamide's knob causes an initial increase of memory by a small amount and then it's pretty stable. It varies but I can't get it to constantly increase.

However it has another issue. After a lot of twiddling the mouse cursor disappears over the whole of Reaper, not just the plugin. The mouse still functions with clicking but no cursor. Rebooted the PC and it's a repeatable issue.

What have you done tula?

Cheers

Spogg

Yep, same here with the disappearing mouse cursor.