Almost certainly, your sample data is stored multiple times within the schematic. This is something you have to watch with any bulk data - waves, bitmaps, large arrays, etc.
Almost all "green" and Ruby FlowStone components store their current values within the schematic file whenever you save it (the same for VST or EXE exports too). This makes startup very fast, as no data needs to be recalculated or moved between components, but as you see, it can take a shed-load of memory, as a "value" can be an entire sample or bitmap (or its equivalent in some other internal format). The likely culprits are any "green" Float Arrays or RubyEdits which have working copies of the data for generating displays, "normalised" versions of sample data, etc. It's not helped by the fact that some data formats can't be shared (a wave contains essentially integer data, internal audio "mems" use native float arrays, and Ruby uses "objects" - each format change implies a copy, and the copy may be stored in the file).
The usual workaround is to save the schematic (or export) with empty wave data (or bitmaps, whatever) and restore it at startup using an "after load" primitive. Whether you want to do that depends on your objectives, of course - sometimes you really do want to "embed" the data to avoid having "sidecar" files. There are similar "after load" tricks you can use if you need to clear only certain internal copies (the "last switch" primitive is your friend here).
NB) There is a built-in optimisation for bitmaps - a single set of data is shared for any bitmap accessed by "yellow" GUI primitives (but RubyEdits will each store their own copy if they use it!!!)
PS) I must say, I'm very impressed at how quickly you are exposing some of FlowStone's most annoying "gotchas"!