On Apr 9, 2012, at 11:34 AM, Martin Peach wrote:
On 2012-04-09 07:31, IOhannes m zmölnig wrote:
On 04/09/12 12:39, katja wrote:
Doing it better would require a lot of modifications, more than changing some format specifiers. It's a pity we can't see MaxMsp's code, the issues seem to be neatly solved there, like:
i haven't looked at the actual behaviour, but max has a (default) binary forma, where it can store numbers without precision loss.
this is of course way easier to implement than trying to save numbers at a "reasonable2 precision in a textfile.
Here is part of a Max5 patch, a multiply object:
"box" : { "maxclass" : "newobj", "text" : "* -57.29578", "numoutlets" : 1, "fontname" : "Arial", "outlettype" : [ "float" ], "id" : "obj-19", "fontsize" : 12.0, "patching_rect" : [ 294.0, 382.0, 73.0, 20.0 ], "numinlets" : 2 }
It is stored as a text file in a format not unlike xml. It may be that floats are stored as doubles inside Max5 but the patcher is saved as text.
With Max5 they switched to a JSON file format. Previously, there was the .mxb format, which is binary.
We could still store numbers as ASCII and not lose precision. For example, we could store the actual bits as base64 or hex. Let's say it'll store 64-bits to have one number format for both single and double precision. Using base64, there would have to be 32 characters to support 64 bits.
While we are at it, it would be good to make the comments totally unparsed, so that things like +14322342342 (phone numbers) or 1. (numbered lists) don't get converted by Pd's type system. Comments do not need to be parsed into types, they should just be treated as UTF-8 text.
.hc
http://at.or.at/hans/