Why we need a real binary file format.

    Oct 22 2008 | 10:43 am
    I've just open a patch with max 5 that has been made with max 4, in order to convert it to a maxpat file. The original patch was a 2,2 Mo mxt file, that max 4 was opening in about 10 seconds, and saving in ~2 seconds.
    With max 5, it takes about 2 mn to load it, and about the same time to save it. And the patch is now 19,3 Mo !!! imagine i drink one coffee each time i want to save my patch, i will soon be an hyperactive ! :-)
    I did a simple test, i "copy compressed" the whole patch, and its size in this format is only 1 Mo ! (it took 3 mn to copy compressed)
    So, Cycling team, you added to max 5 the copy compressed feature some times ago, it should not be to hard to add an option to save the patches in this format... I really don't know if doing this will speed up the loading and saving time, because i think max 5 is handling patches in memory in the json format, and would have to convert to the compressed format before writing the file and uncompress when loading, but it would be more friendly for our hardrives.
    Is there a chance you can do something about that loading/saving time ? (like using a real binary file format)