Serious memory problem in 3.08.1 on all VST - even stock!

[lalalandsynth]

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

[tulamide]

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.

[Spogg]

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

[lalalandsynth]

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.

[pshannon]

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.

[tulamide]

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

[adamszabo]

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.

[lalalandsynth]

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 ?

[Spogg]

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

[lalalandsynth]

Yep, same here with the disappearing mouse cursor.