custom copy methods

[catfact]

get your OOP act together and write custom copy methods for preset_t, scene_t, ctlnet_t, and whatever other big data classes are being blindly memcpy'd with impunity all over the dang place.

[catfact]

the memory stuff is weird because we have an SRAM that is not allocated from the heap. instead, the chip has a hard-coded address. there is a super-primitive system to allocate pointers to SRAM in avr32/src/memory.c , and no mechanism to free them. we could theoretically fix this by mapping the SRAM to heap in the memory map, but my abortive attempts at this were highly frustrating and wasted a lot of time.

anyways, my approach is to basically think of all of these data structures as statically allocated. memcpy should be fine and appropriate, except evidently some pointers to heap-allocated structures are sneaking in somewhere. probably a fucking string or maybe a function pointer. probably specific to the single extant momome grid operator.

[catfact]

still, might be safer to implement custom copy methods in the proper fashion.

[catfact]

belatedly realizing that of course certain things in this system will break between builds if operator layouts, etc change drastically.

obviously this is happening a lot right now. we could assume layouts will not change between major releases or something. i'm not really sure of the right way to handle version numbers but ship should be 0.x "beta" . can deal with compatibility when we want to break it ?

[catfact]

iss 49:

need deep-copy on ctlnet ?

case: scene is written with older version of bees
struct layouts for ops and everything are different.
loading the scene gives garbage.

so, scene file needs to store bees version number.
then we can knowingly break compatibility as long as we maintain inter-version translation routines.

obvs, would be safest to have deep-copy methods for everything,
even though this runs to a lot of code and is boring.
of course, have to do it sooner or later in order to have x-platform file parsing.

q: can struct layout ever change between builds because of optimization level or other non-coding reason? it would be nice to enforce packed everywhere, but having trouble with this when nesting structs with gcc.

[catfact]

using class-defined serialization methods, closing this and making #64