From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
So, I was beginning to think 47.5MB for an OSM was a slightly too large, so I reduced 1 background module that was used 9 times inside the OSM. By using these tips + more, I took out about 2/3 of the primitives & links. Later cut & pasting the said module into a new OSM then saving just those modules alone, the old version (uncompressed) was 3005 bytes compared to & the new was 681. But in the OSMs that they are used in, the new OSM gained over 433,000 bytes! All from reducing 1 smaller module that was synced 9 times!
edit: Just copy & pasting the said background module then deleting the old one increased uncompressed filesize by 8k. Should have stayed the same since there is the exact same number of primitives & links.
Tip: use 7zip to find uncompressed file size.
Something is very wrong in SM's saving system; I'm guessing keeping Undo info inside the OSM, not deleting old primitives/modules, or something weird.
Good news is opening & editing the huge OSM is much faster than older (<SM1.6) SM versions.
Bad news is copy/pasting lagers modules still takes a few minutes.
infuzion ·
related: copy/pasting slow SM2.0.4: copy/pasting large modules slow
trogluddite ·
infuzion wrote: there is the exact same number of primitives & links
Could the content of the modules/prims be part of the issue? - remeber SM doesn't just save the schematic, but also the data contained within primtives (e.g. bitmaps, array contents etc.)
infuzion ·
I don't think there are any bitmaps. There are ALOT of arrays, I'm sure that is causing the large filesize.
But when you remove primitives, file size should decrease, not increase. When you cut a module, then re-paste that same module back in, the file size should stay the same, not increase.
trogluddite ·
Yes, certainly sounds like something amiss with what or how SM is storing things - just thought I'd check in case there might be something now stored rather than calculated on the fly.
Brings to mind the issues I've had in the past with the memory management of buffers - assigning a new chunk of memory for every re-compile instead of re-using or freeing up the old memory space, until crashing when there was no memory left. Not had that for a while, guess Malc must have fixed it - but it sounds like a similar kind of problem. As if there are 'ghost images' of former modules getting trapped inside the schematics.
infuzion ·
trogluddite wrote: ...As if there are 'ghost images' of former modules getting trapped inside the schematics.
While preparing a response to Malc's response, I did the following test:
Open up Example.osm, cut & paste back in some modules... for my test I used the ADSRs. With out reconnecting back the ADSRs after the re-paste, the file size grew by almost 4k; file size should be smaller due to the missing links!
trogluddite ·
Ouch 😮 - that is worrying - so, in effect, every substitution of a primitive/module when prototyping is potentially eating unnecessary memory and disk space.
Had a funny (?) thought - maybe SM was supposed to have a system that remembered Undo/Redo states even after saving!
infuzion ·
+ the fact the way SM is built you are encouraged to prototype as you go along, so you have alot of revisions...
MyCo ·
The problem seems to be the compression system. I tried infuzions test, and the file size of the compressed file increased, but the uncompressed file decreased (one link is deleted)
infuzion ·
MyCo wrote: The problem seems to be the compression system. I tried infuzions test, and the file size of the compressed file increased, but the uncompressed file decreased (one link is deleted)
In my first picture, I show file size uncompressed using 7zip to find the "real" file size. In my example.osm example, the original is 760,847 bytes, & after copy pasting it is 764,999 bytes, both uncompressed.
infuzion ·
A bit of follow up from Malc:
He found that in my private OSM, I had a testing Float Array that the array size kept growing & not being cleared. After deleting that array (size was in the millions & was cloned 4 times), the uncompressed file size went from the 46Mb that you see here to about 1.2Mb. So that helps 😉
He did see that cut & pasting the ADSR in the example.osm did increase filesize by 5k: "most likely down to a combination of bitmap caching and maybe the compression". I'm trying to get him to fix that.
infuzion ·
Another followup: seems that cutting & pasting randomly increases or decreases file size. Not to big an issue now; considered closed, but should keep an eye out for a pattern or bigger bad examples.
trogluddite ·
infuzion wrote: cutting & pasting randomly.
Sounds like an interesting way to make a new synth! 😉
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker