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.