Reduce File Size

Here is a listing of tips to reduce your file size, likely to make your OSM load/edit/run faster in SM, and perhaps make your exported EXE/VST smaller.

Primitives/Modules

  • For files you are about to send off, go through all your modules (sync helps here) and delete all unneeded knobs, Analysis modules, Floats that you are using just for test readouts, etc.
  • Delete all those Tooltip Help primitives & connected Text of SM modules. You don’t need that help now & you can read their help while mousing over them in the Toolbox. Might be helpful if you add a String inside modules, or edit the “module” name, with the source information (author/SM version) of where you got the said module from, since modules change around inside. Exception: For modules you wrote yourself, you should add a Tooltip for modules you are about to email/post, it is wise to add a Tooltip with module name, 1 line explanation of what it does, your name (& those who helped) & contact info.
  • Delete all those silly “Preview” and other pergeable modules (they have a black & yellow stripe around the edge). If they are inside knobs and other frequently cloned modules, this method may save time:
    1. Right-click over the outer module (eg over the knob, etc)
    2. “Synchronize all”
    3. remove the items and do other global editing inside the module
    4. go back outside the outer module, then “Un-synchronize all”
  • Avoid making too many sub-sub-sub-modules.
    • Readability of your OSM is important; instead of making a group into a module, you can label the links well, and label the last primitive of an equation with what it does
    • If your file is too large, people with limited memory may not be able to even open your OSM, and perhaps edit it!
    • Remember making a group of objects (links, primitives, & sub-modules) into a module increases the number of primitives needed for the extra links, and the links themselves take up memory.
    • The deeper a wireless receiver goes, the more links it needs, & the harder it is to find it.
    • If you have a module that presents only 6 objects, consider pulling up a sub-module. This will save memory and speed of opening, saving, and editing.

Math

* 99% of the time, you can remove all Floats & Ints that only have a zero (0) value. No input = 0 or empty string

* Use algebra reduction to reduce the number of math operations, thus reducing both file size (fewer primitives) and CPU (fewer calculations).

Warning: Sometimes reducing code by using fewer math primitives will make the file size smaller, it can make your schematic slower when data is run though it. Always consider speed of execution as well as file size.

Text

The Text primitive is a poor way to store array data; it uses more file space, slower to connect up, and perhaps has a slower reaction time in use. To replace:

  1. drop an Array Sample & Hold next to the Text
  2. carefully disconnect an out of the Text into the top in of the Array Sample & Hold
  3. trigger the trigger-in of the Array Sample & Hold (AS&H) just once
    • connecting then disconnecting a second out from the Text will work; be careful
  4. fully disconnect the AS&H by [Shift+Ctrl+L]-Remove Links
  5. test, by connecting the out of the AS&H to an in of another Text
  6. you should have a loaded AS&H!
  7. you may want to connect the AS&H like the Text was, but connect the AS&H‘s trigger in from the source on a second connection (link order counts) if you need data to flow though it.

Note: If you copy the Text data into the clipboard, paste it into a text editor, then copy it from the editor back into a Text, you may find the formatting is wrong (no linespaces). If that is true, fix it in your editor by changing the line delimitation format to Mac/CarriageReturn.

General

  • Try to straighten as many links as your eyes can stand. Each curve you put in a link might add very little to the file/memory size of the schematic, but if you have 1000s of curved links, you’ll start noticing SM getting a bit draggy. If you keep your OSM well organized, then you should not need so many links inside a single level of a module anyway.

Test

Sometimes you can “break” a module by not reconnecting things in the correct link-order, to the wrong place, or forgetting something all together. It is very important you test & save as a new file name often to catch these bugs early. If you feel disgruntled by how much work you did, but how little KB you actually seemed to reduce, you need to find the "real" file size.

tutorials/reduce_file_size.txt · Last modified: 2008/12/01 05:55 by infuzion