VL: Serializer stumbles over IOBoxes in types

Why are patch-internals like io-boxes even serialized in the first place? Can’t they opt-out?

Can’t believe @gregsn actually said this, as an argument against generic serialisation:

because as a patcher you should not even try to be boss of the serialisation format for your stuff and handcraft it. Not in this day and age anyway, and for good reason.

Writing a custom XElement serialiser should only be recommended for projects with a long-lasting duration of development and resulting compatibility issues between versions due to internal restructuring and frequent public updates.
But in most of project work you would only want to write down the contents of your record, in the rarer complex case you would want to have some moderation in what get white- or blacklisted from the transmission data, and if only for size optimisations.

Anyway, my point is, the actual serialisation work should be done by any tried-and-tested serialisation nuget you want (msgpack, json.net, fspickler, even protobuf-net).

Of course serialisation is only one reason why we need Attributes for at least Patches, Properties and Members.

In this case, the vl editor would allow you to simply “tag” the Pads you want to be in the transmission instead of handpatching cumbersome serialisation mechanisms that usually directly mimick your original Record, but in a horror mirror kind of way.

2 Likes