If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
Serious memory problem in 3.08.1 on all VST - even stock!
Re: Serious memory problem in 3.08.1 on all VST - even stock
Im on Win 7 32 bit FL Studio.
But on closer look im getting the same as spogg. It kinda increases but very slowly, not as fast as the others. Then it seems to stop doing it.
Im getting the dissapearing mouse cursos as well if I constantly switch between the task manager and fl studio.
Btw can you guys check this dll too?
But on closer look im getting the same as spogg. It kinda increases but very slowly, not as fast as the others. Then it seems to stop doing it.
Im getting the dissapearing mouse cursos as well if I constantly switch between the task manager and fl studio.
Btw can you guys check this dll too?
- Attachments
-
- test_volume_knob_2.zip
- (1.83 MiB) Downloaded 1007 times
- adamszabo
- Posts: 667
- Joined: Sun Jul 11, 2010 7:21 am
Re: Serious memory problem in 3.08.1 on all VST - even stock
adamszabo wrote:
Btw can you guys check this dll too?
Hi Adam
Your knob VST continues to increase the memory as I twiddle. Plus it still shows the mouse cursor issue.
Cheers
Spogg
-
Spogg - Posts: 3358
- Joined: Thu Nov 20, 2014 4:24 pm
- Location: Birmingham, England
Re: Serious memory problem in 3.08.1 on all VST - even stock
Usually this mouse cursor issue happens if you call showCursor in mouseLUp instead of mouseLUpCaptured.
mouseLUp only gets called if the cursor is over the view (which it might not be if you captured the mouse).
mouseLUp only gets called if the cursor is over the view (which it might not be if you captured the mouse).
- TheOm
- Posts: 103
- Joined: Tue Jan 28, 2014 7:35 pm
- Location: Germany
Re: Serious memory problem in 3.08.1 on all VST - even stock
Well this is getting progressively weirder!
I have a Linkx 1010B tablet running Windows 10 32 bit with 2GB RAM
I thought I’d test the memory issue on this.
My Ruby knob did the same memory thing as on Windows 7, the SM knob was still ok.
The mouse issue on the vector knob was the same.
However, and this is something I just don’t understand, when I tested my 4EA+ and also the Harvester I got NO memory increase no matter what I did, including rapid twiddling of any knob or control. This was tried with Record set and not set. I should add that both plugins worked fine, much to my surprise.
Go figure!
Cheers
Spogg
I have a Linkx 1010B tablet running Windows 10 32 bit with 2GB RAM
I thought I’d test the memory issue on this.
My Ruby knob did the same memory thing as on Windows 7, the SM knob was still ok.
The mouse issue on the vector knob was the same.
However, and this is something I just don’t understand, when I tested my 4EA+ and also the Harvester I got NO memory increase no matter what I did, including rapid twiddling of any knob or control. This was tried with Record set and not set. I should add that both plugins worked fine, much to my surprise.
Go figure!
Cheers
Spogg
-
Spogg - Posts: 3358
- Joined: Thu Nov 20, 2014 4:24 pm
- Location: Birmingham, England
Re: Serious memory problem in 3.08.1 on all VST - even stock
Let me start with the cursor issue, because it is not related to the memory leak:
So, I used a vector knob for a specific reason; to exclude any issues that might arise from reserving memory for pictures converted to bitmaps. This knob only uses the view bitmap (draws directly to the view). Also, the test is reduced to pure Ruby, to concentrate on this issue alone.
It is totally normal for any process to increase memory usage during execution. It can't foresee the future. If things are defined later, bitmaps get loaded in later, audio is recorded to mem, etc., it will reserve that amount of memory during execution, not in the beginning. And of course it can't release memory that's still being used.
But there's also a clear difference between normal memory increase and a memory leak. In the first dll (the one I posted), there obviously is no memory leak. It acts as expected (yes, we ignore the cursor issue).
The second one (posted by Adam), does have a typical memory leak.
Both are exactly the same schematic. Both are exported exactly the same way. But, number one was created with 3.0.6 and number two with 3.0.8.1. The comparison was important to exclude the rumours that there would still be an old synthmaker leak in there.
The issue therefore is reduced to one spot for MyCo to look at: The export mechanism. Something has changed between 3.0.6 and 3.0.8.1 in the way Ruby code is embedded during export. It might be another Ruby version or a mistake in the programming of the export routines (I wonder what would happen if Ruby got loaded with every knob move ). There's still a lot to investigate. But MyCo can concentrate on the export routines and dependencies and I hope this saves him a lot of time.
But let me also be clear: It is not an issue from Ruby.
Indeed, TheOm spotted the issue. I created the knob long before we were aware of the mouseLUp issue. mouseLUpCaptured was never documented, so we all used the prior. I used the "Show Cursor" prim to keep the mouse in place, and this prim needs a boolean, which is switched by mouse down/up events. I will correct the issue and post on Flowstone GURU.TheOm wrote:Usually this mouse cursor issue happens if you call showCursor in mouseLUp instead of mouseLUpCaptured.
mouseLUp only gets called if the cursor is over the view (which it might not be if you captured the mouse).
So, I used a vector knob for a specific reason; to exclude any issues that might arise from reserving memory for pictures converted to bitmaps. This knob only uses the view bitmap (draws directly to the view). Also, the test is reduced to pure Ruby, to concentrate on this issue alone.
It is totally normal for any process to increase memory usage during execution. It can't foresee the future. If things are defined later, bitmaps get loaded in later, audio is recorded to mem, etc., it will reserve that amount of memory during execution, not in the beginning. And of course it can't release memory that's still being used.
But there's also a clear difference between normal memory increase and a memory leak. In the first dll (the one I posted), there obviously is no memory leak. It acts as expected (yes, we ignore the cursor issue).
The second one (posted by Adam), does have a typical memory leak.
Both are exactly the same schematic. Both are exported exactly the same way. But, number one was created with 3.0.6 and number two with 3.0.8.1. The comparison was important to exclude the rumours that there would still be an old synthmaker leak in there.
The issue therefore is reduced to one spot for MyCo to look at: The export mechanism. Something has changed between 3.0.6 and 3.0.8.1 in the way Ruby code is embedded during export. It might be another Ruby version or a mistake in the programming of the export routines (I wonder what would happen if Ruby got loaded with every knob move ). There's still a lot to investigate. But MyCo can concentrate on the export routines and dependencies and I hope this saves him a lot of time.
But let me also be clear: It is not an issue from Ruby.
"There lies the dog buried" (German saying translated literally)
- tulamide
- Posts: 2714
- Joined: Sat Jun 21, 2014 2:48 pm
- Location: Germany
Re: Serious memory problem in 3.08.1 on all VST - even stock
Totally excellent investigative work tulamide (as expected!)
But I still don't get my Windows 10 results
Cheers
Spogg
But I still don't get my Windows 10 results
Cheers
Spogg
-
Spogg - Posts: 3358
- Joined: Thu Nov 20, 2014 4:24 pm
- Location: Birmingham, England
Re: Serious memory problem in 3.08.1 on all VST - even stock
@ Tulamide. The knob you posted does leak on win 7 . But not on win 8 .
-
lalalandsynth - Posts: 600
- Joined: Sat Oct 01, 2016 12:48 pm
Re: Serious memory problem in 3.08.1 on all VST - even stock
lalalandsynth wrote:@ Tulamide. The knob you posted does leak on win 7 . But not on win 8 .
It does not. Read my explanations and the test results of the others.
"There lies the dog buried" (German saying translated literally)
- tulamide
- Posts: 2714
- Joined: Sat Jun 21, 2014 2:48 pm
- Location: Germany
Re: Serious memory problem in 3.08.1 on all VST - even stock
I will post screenshots.
-
lalalandsynth - Posts: 600
- Joined: Sat Oct 01, 2016 12:48 pm
Re: Serious memory problem in 3.08.1 on all VST - even stock
Volume knob test opened in Reaper 5.4 , Win 7 . Tested on 2 computers.
Took quite some wiggling and patience but it leaks.
Initial Memory before moving.
After about 6 minutes of wiggling the knob....it seems much slower then other tests but still leaks.
Therefore I will suggest you guys on Win 7 test this again , taking into account that its slower then other leaks.
After I stop moving the knob it does not let go of the memory.
Does not do this on my Win 8 machine but leaks on both Win 7 machines.
I have no clue why , I can only report what I am seeing here.
Took quite some wiggling and patience but it leaks.
Initial Memory before moving.
After about 6 minutes of wiggling the knob....it seems much slower then other tests but still leaks.
Therefore I will suggest you guys on Win 7 test this again , taking into account that its slower then other leaks.
After I stop moving the knob it does not let go of the memory.
Does not do this on my Win 8 machine but leaks on both Win 7 machines.
I have no clue why , I can only report what I am seeing here.
-
lalalandsynth - Posts: 600
- Joined: Sat Oct 01, 2016 12:48 pm
Who is online
Users browsing this forum: Google [Bot] and 62 guests