Ram-saving suggestion

[Matth23u]

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...

[wlangfor@uoguelph.ca]

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

[Matth23u]

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...

[wlangfor@uoguelph.ca]

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

[trogluddite]

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.

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.)

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.