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
    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
    it should not be to hard to add an option to save the patches in this
    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)