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

[lalalandsynth]

So I have been trying to chase down this memory leak.

I first encountered this with the advanced envelope, traced it to the play position bar.
Then I removed that and the leak stopped, however , I noticed that when I moved a knob it started to leak.

So I went back to basic modules that come with FS , Echo delay - Compressor - Chorus etc.
Exported as vst ..stable in memory until I move a knob , then the memory increases....and stays that way !
This happens with everything I export as vst.. stock modules included - except for Phenom And BobK Synths for some reason, I can only guess that its made in a much earlier version ?

All sequencers from Nubeat7 with a moving position bar will cause a leak, let alone if you move any knobs.
It seems that the memory leak slows down when the gui is not shown, but still there.
Everything tested in both 3.08 and 3.09- also uninstalled, removed everything flowstone, ran a cleaner, reinstalled.

@Spogg.. exporting your Harvester from 3.08.1 - opening in Reaper - hitting play bar and not even playing the synth, its just sitting there and the memory usage grows and grows. Let alone if you play it, grows for a 0,5 Mb a second.

I have tried 3 computers , 3.08.1 and 3.09? I can hardly believe I am the first one to notice this ? This is a major problem as far as I can tell .For example -My project uses 2 advanced envelopes, two lfo´s , two circular sequencers and a moving filled slow scope. The memory leak is massive.

I can provide a bunch of examples , but let's try something basic. Here is the stock compressor as a FSM , export from 3.08 as VST, open in your daw.. open task manager , move a knob continuously or automate it and watch the memory grow.

Stock compressor.fsm

(63.94 KiB) Downloaded 1059 times

Can someone confirm this please ? I am still having a hard time believing that I am the only one that has noticed this but I think I can say with confidence that this cannot be an issue for me only as I have run out of ways to test this!? If there is something wrong on my side I would LOVE to know. Please tell me I am going nuts or something.

I also made some gifs
1. Stock echo delay module - watch the mem increase when I move a knob.
https://media.giphy.com/media/3og0IHeEs ... /giphy.gif
2. Quilcom Harvester - Idle - creeping mem increase - played - gets faster.
https://media.giphy.com/media/xUA7aNiQX ... /giphy.gif

[lalalandsynth]

Went back one version to 3.08 . Exported stock chorus flanger.
Same thing.

[Spogg]

I just tested this on my current project which is very large and has some moving graphics.

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.

Checked with the latest test alpha in Windows 7 64 bit and got the same leakage result. Carried on if I switched focus to the calculator and no change. Stopped when I deleted the plugin when the bridge closed down, Reaper itself was stable in terms of memory use, just the bridge for my plugin was leaking.

If you can possibly identify if there's a specific component or component type (e.g. those that use Ruby) it would help to isolate the offending prims/dsp etc. Then the devs will have a chance to isolate the issue, which I agree is serious.

I don't normally run my plugins for very long, just for testing mainly, so I guess I never saw the consequences.

Cheers

Spogg

[lalalandsynth]

I am still testing, its very hard to pin down , it is in all stock modules I have tested so far.
Most seem to slow down(not stop) on the mem leak when gui is down , but not all.
Most seem to be worse when moving graphics , moving knobs but not all.

Super hard to track...

I am conflicted here , relieved that its not only me going mad but concerned about when we could expect a fix for this.My plugin is unusable as it stands, playing with it for 15 minutes and its reaching a gig or more.
I tested Harvester again and stopped 9it when it was at 700 mb.


Also note, this spikes the CPU as well, it seems . When I remove the play pos from the advanced envelope the cpu drops by 14% , this might be a graphic issue and normal, At this point i am paranoid.

Only ones I have found that do not do this are phenom and BobK synths.

I would appreciate the Devs pitching in on this issue.

[MyCo]

Posted this on facebook:

This can actually be normal. If this would happen without any Ruby code, then it would be concerning. I'll do some checking but I think that this is just normal Ruby behaviour. The memory is increased till the garbage collector runs

[lalalandsynth]

I hope this is not normal behaviour.

I ran Harvester for 26 minutes.

Quilcom - started .

Quilcom 1.jpg (77.91 KiB) Viewed 30439 times

Quilcom - after 26 minutes.

Quilcom 2.jpg (89.72 KiB) Viewed 30439 times

[lalalandsynth]

I also ran Advance envelope for 12 minutes

Advanced Envelope-Started.

Advance envelope test first.jpg (75.08 KiB) Viewed 30439 times

Advance envelope after

Advance envelope test 2.jpg (103.08 KiB) Viewed 30439 times

[lalalandsynth]

My plugin that contains 2 advanced envelopes , 2 circular sequencers , and 2 synced lfo´s and a steady scope which all eat memory used alone will reach 1.5 gig in a typical production session of 20 minutes or so.

About 130-40 when opened.


Here is a gif
https://media.giphy.com/media/3ohrylfgE ... /giphy.gif

[lalalandsynth]

I am done testing for today.

Testing.jpg (61.95 KiB) Viewed 30432 times

[tulamide]

A few things to consider:

Whenever Ruby is involved it is normal that memory goes up a while. Ruby uses an intentional lazy garbage collector. That essentially means not interfering when already busy. The garbage collector will free memory when it gets time to do so and there is a certain amount of operations on the stack.

But, and here comes the second point, often times people underestimate the power of triggers. While there are, say 128 reasonable steps to draw something, the triggers created by moving a knob are much higher than that. It can easily go into several hundreds per second. If you connect a RubyEdit with something that produces so many triggers, it will never get a chance to free memory.

In conclusion, for all drawing operations you need to reduce triggers to a reasonable amount. Perfect would be one trigger per possible change in the graphics, and don't run a ticker25 or ticker100 on a graphic related RubyEdit. The ticker will continously trigger the RubyEdit and chances are high that it will never have the time to free memory.

Also, with asm involved you might have to release memory manually (I'm not sure about that, Gurus please say something) or it will stack infinitely.