Support

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

Ram-saving suggestion

For general discussion related FlowStone

Ram-saving suggestion

Postby Matth23u » Fri May 24, 2019 7:29 pm

Hi, could it be possible to function-strip unused module content?
Say, imagine i've got a module packed with functions but that most of them are unused, could the unused part of the generic code be stripped so less ram is used? And reactivated on demand, if needed.
My synth takes nearly 2gb of ram, that's a real lot and it doesn't have this much content... And i doubt it's the small size PNGs that takes all that ram uncompressed... Also, i feel like code elements, when plugged to a selector, are all active while those unselected shouldn't be active... Taking more cpu than it should...
User avatar
Matth23u
 
Posts: 44
Joined: Fri Mar 29, 2019 12:58 am

Re: Ram-saving suggestion

Postby wlangfor@uoguelph.ca » Fri May 24, 2019 8:27 pm

Matth23u wrote:Hi, could it be possible to function-strip unused module content?
Say, imagine i've got a module packed with functions but that most of them are unused, could the unused part of the generic code be stripped so less ram is used? And reactivated on demand, if needed.
My synth takes nearly 2gb of ram, that's a real lot and it doesn't have this much content... And i doubt it's the small size PNGs that takes all that ram uncompressed... Also, i feel like code elements, when plugged to a selector, are all active while those unselected shouldn't be active... Taking more cpu than it should...


lots of selectors and multiplexers
My youtube channel: DSPplug
My Websites: www.dspplug.com KVRaudio flowstone products
User avatar
wlangfor@uoguelph.ca
 
Posts: 912
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada

Re: Ram-saving suggestion

Postby Matth23u » Sat May 25, 2019 12:16 am

Well... That's not what i meant.

Some primitives have much more options than needed. Stripping the unused parts could save ram.

B.t.w... PNGs seems to take tens and tens more megabytes than they should... Is that just an impression or does flowstone uncompress them RAW and make 60k files 20mb?

On the synth that i shared with you, i use 1x instance of each used bitmap which are then mirrored through wireless on every knobs. I saved a lot of ram doing so... but it's seemingly still not enough.

It's not obvious what makes such a tiny and huge synth take so much ram...
User avatar
Matth23u
 
Posts: 44
Joined: Fri Mar 29, 2019 12:58 am

Re: Ram-saving suggestion

Postby wlangfor@uoguelph.ca » Sat May 25, 2019 2:17 am

Oh, yes I understand what you mean. But I mean You can always have two versions one with less function and the other with more.

Or let's say if You're accessing a large array. Use array gets to only access the info that You need with the currect indexes.

GL
My youtube channel: DSPplug
My Websites: www.dspplug.com KVRaudio flowstone products
User avatar
wlangfor@uoguelph.ca
 
Posts: 912
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada

Re: Ram-saving suggestion

Postby trogluddite » Sat May 25, 2019 3:31 pm

lalalandsynth wrote:Some primitives have much more options than needed. Stripping the unused parts could save ram.

Is what you're asking possible? In principle, yes. By customers such as ourselves? No chance. By DSPr/MyCo? Possibly, but it would be an enormous amount of work and a huge new source of potential bugs.

An FS plugin export is basically just your schematic wrapped together with a "non-GUI" version of the FS workspace engine and the Ruby interpreter (hence the size even of an "empty" plugin's .dll). The "features" of primitives are just functions, so each would be defined only once in the workspace engine's code (but called with different data for each separate instance.) To exclude the definitions of unused primitives, features, or Ruby methods, there would be two choices...

1) To keep the current "static linking" (i.e. whole plugin in a single .dll file), you'd have to recompile the FS/Ruby engines from their C++/C# source code for every export, taking note of which code is ever called and which is not. In essence, you'd have to include a Visual Studio compatible C++/C# linker/compiler with an incredibly complex conditional linker - far from a trivial thing, as anyone who's ever scratched their head about linker errors in Visual Studio can attest.

2) To allow dynamic linking (i.e. loading/removing code at run-time), the separate parts of the code would each have to reside in their own .dll file (dll = Dynamically Loaded Library) - and you would have to include those separately as part of the install or have them extracted from an archive and saved to disk at plugin load-time. This did used to be done with the Ruby interpreter, but doing it this way can look very like the behaviour of malware, so it's now statically linked instead after complaints about it.

lalalandsynth wrote:Also, i feel like code elements, when plugged to a selector, are all active while those unselected shouldn't be active

So long as there is no route from any of a mono/poly component's outputs, it will be turned off (i.e. always select outputs rather than multiplex inputs.) In fact, it won't just be "turned off", it will be removed from the processing chain completely (it's recalculating the processing chain that often causes the audio 'splats' whenever mono/poly selectors or multiplexers are switched - it's quite a big CPU spike sometimes.)

lalalandsynth wrote:PNGs seems to take tens and tens more megabytes than they should... Is that just an impression or does flowstone uncompress them RAW

Yes, compressed bitmap formats will be expanded upon loading. The GDI+ engine which deals with graphics rendering can't handle bitmap data any other way. Even if it could, decompression at every single redraw would eat even more CPU power than it already does. The only way around this would be for FS to switch to a hardware accelerated graphics engine - as well as lowering main CPU load, it would allow use of the graphics card's memory for bitmap data.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK


Return to General

Who is online

Users browsing this forum: No registered users and 46 guests