Memory Usage (Font Rendering Engine)

[matti]

I'm building a simple little midi/sysex editor vsti plugin and am a bit concerned about it's Ram usage.
It's only 4 part multitimbral with around 200 parameters per part + 200 for the multisetup, so around 1000 parameters. It's taking up 860mb when opened in FS 3.03 and around 360mb as a vsti.

Is there some things i should take special care of when building stuff like this to keep the ram usage down?

I know it's a bit large schematic to begin with (over a million primitives, close to a hundred thousand modules), but it runs perfectly fine and uses close to no cpu at all when operated. So performance is just fine. Any tips & tricks for Ram use?

[matti]

Now that i thought about it for a while it must be something with the bitmaps, right?
There's nothing else that should take up that amount of memory, and there's plenty of bitmaps in here.

Any experience on using bitmap arrays for knobs better than bitmap reads with area controls?


edit: Ah, no. Couldn't find the ram usage problem from bitmaps. New ideas?

[nix]

Yes-
try looking at 'mems' and float arrays.
I guess preset parameter arrays also-
try these.
All success

[matti]

I've actually now tried that.
Removed a huge number of arrays i thought might be causing some ram use... but no (big)change.
Might just be that I've simply used too many primitives.

Some sort of schematic profiling would be nice.. Devs?

[trogluddite]

I'd strongly suspect the bitmaps too. If you have used all your own custom images, try putting them into a single folder to see how much room they take up.
Using bitmap arrays shouldn't really make much difference - the overall "area" covered should be the same, so I doubt there would be much difference in file size.
Might be worth looking at the images in an image editor - most control images use a pretty limited palette of colours, so you might be able to squeeze the compression settings or colour depth a bit to save some space.

If you haven't already, look out for controls that share the same bitmap - you can extract the bitmap loader from one of them and use wireless links to share the same bitmap among the controls. IIRC, that won't save much memory because FS looks out for identical image files, but it will make experimenting will different image formats, cell counts etc. much easier - you just load the file once, and all identical knobs will update, instead of doing them one at a time.
(If they are Ruby controls, don't forget the "After Load" trigger for the bitmap, otherwise Ruby won't see the new images when you re-load the schematic).

[RJHollins]

If you haven't already, look out for controls that share the same bitmap - you can extract the bitmap loader from one of them and use wireless links to share the same bitmap among the controls. IIRC, that won't save much memory because FS looks out for identical image files, but it will make experimenting will different image formats, cell counts etc. much easier - you just load the file once, and all identical knobs will update, instead of doing them one at a time.

just following along to learn ....

mmm ... I have to give this a try to see if I understand how TROG is saying to do this.
I mainly use bitmap knobs, and some of them have the same number of cells.

I also have several 'separate' modules that have common components [like a basic background template]. Currently I copy each of these 'backgrounds' into each of my sections. I never quite figured out how to make a 'master' template, and use that to 'wireless' send that to each module. This is something that I'd like to eventually add to my programming style and skill.

Thanks for the info !!

[trogluddite]

Here's a very quick example of the sort of set-up I usually use...

Bitmap Sharing.fsm

(19.36 KiB) Downloaded 933 times

Couple of things to notice...
- Inside the knob, there's no loader, just a wireless link 'knob bitmap'
- The 'knob bitmap' module contains the loader - I usually have a few of these, one for each unique bitmap (hence it's not just labelled 'loader'). Note also the 'After Load' and other trigger links going to the output - these ensure that Ruby receives an event when the bitmap changes.
- Module 'REFRESH BITMAPS' - just sends a wireless trigger to the loader, bypassing the file dialogue prim'. I usually send this to ALL my loaders - then, whenever I've been using Knobman/GIMP/PS etc. to do some editing, I can just click one button and all my graphics update without having to go through loads of file dialogues (as long as the file names have not changed, of course!).

It takes a little bit of setting up, but it really speeds up the tweaking of a GUI - and it's easy enough to pop some 'wireless' versions of the controls into the toolbox. Note that until you load a bitmap, some 'wireless' controls might show a Ruby error when you drag them in - it doesn't like to display 'empty' data, but will recover as soon as you load something. (or see HERE for a Ruby tweak to avoid the error).

[RJHollins]

Thanks TROG !

I'll be studying this.

Just to mention, though ... there seems a discrepancy in the way 'sweep angles' are defined
between KnobMan and FS [RUBY]. Maybe I'm still too new to all this, and confusing something ... or
Is there a different 'reference' point ?!?!?

[matti]

All things you've mentioned are viable ways of reducing ram usage. Those things though are quite obvious and i had already fixed them early on. But now i think i finally found the real problematic part that eats up RAM: THE PARSER!

I've used the custom font rendering engine by Rudolf Lindner(?) alot on things i've done, mostly because i like the small and accurate font that it renders and it's not dependent on fonts installed on a system. It includes a parser for creating an array of ASCII codes from a string. When i remove the parser the memory usage drops drastically.

I did a test run: 500 controller screens - equivalent to 500 knobs i usually use.

Memory usage
With parser: 425MB - FS 50MB = 375MB
Without parser: 235MB - FS 50MB = 185MB
(FS itself eats around 50MB)

So the parser quite literally doubles the RAM use in this test.
I'll investigate more...

[matti]

I did a test run: 500 controller screens - equivalent to 500 knobs i usually use.

Memory usage
With parser: 425MB - FS 50MB = 375MB
Without parser: 235MB - FS 50MB = 185MB
(FS itself eats around 50MB)

So the parser quite literally doubles the RAM use in this test.
I'll investigate more...

I made a fixed version of the font renderer and replaced the parser with a simple String to Array primitive (Str2Arr).
Memory usage: 128MB - FS 50MB = 78MB

That should do it


edit: Applied this to the plugin i was working on: Already halved the RAM use.
edit2: Done applying this fix to all parts of the plugin.
Results:
RAM usage down from 860MB to 410MB
Schematic file size down from 6.9MB to 2.6MB


Stay clear of the parser!