how to store a buttload


    Jan 27 2006 | 12:43 am
    my external provides access directly to a relational database.
    the users would like to be able to store the database info (which can
    be quite big) in the max patch.
    the database info is typically stored as an XML file. optimistically
    spoken the database is about 3 MB.
    realistically spoken, it's about 64 MB. zlib will bring that down
    significantly...
    but... HOW do i get it into my binbuf... using binbuf_text()
    crashes if I pass a pointer to my XML data.
    what I would like to see is :
    short binbuf_bin(void* bb, char* data, long numBytes);
    i understand that if you were to use binbuf_bin to store for example
    sample data in the max patch, if the end-user were to open up the max
    patch as a text file there would be a (very) big binary fart there.
    in my case they would probably see alot of XML stuff (if i don't
    compress it)...
    the typical (provisional) solution to this problem is of course to
    store the binary data into a seperate file, and store the path to
    that file in the binbuf. that's of course what i have to do for
    now... but... the big problem is that if the user copies the max
    patch (to a different machine for example) and forgets to copy the
    data file along with it (and put it in the right place...) well, it
    just don't work no more and causes headaches for the user.
    any ideas? thanks!
    |K<

    • Jan 27 2006 | 11:43 am
      Hi Kent,
      I don't know what the maximum amount of data a binbuf can carry, but it
      would be good to know. I will also be pushing the limits in a project
      I'm working on.
      Idea 1: You might be able to build a work around by encoding, say, 1MB
      at a time to binbuf_text(). Either using multiple binbufs or filling
      one, processing it, and clearing it before starting the next MB (sorry,
      I don't have the API in front of me right now, so I'm not sure exactly
      how this would work, but you get the idea...)
      Alternately: if you save your data to a separate file, can you wrap
      everything up in a Bundle? (At least for Mac OS). There is extra work
      involved, and obviously the one-big-file approach would be more
      convenient. But for the user at least it looks like a single file.
      I will be interested to hear what solutions you reach.
      -- Peter
      On around Jan 27, 2006, at 1:47, Kent Clelland said something like:
      > realistically spoken, it's about 64 MB. zlib will bring that down
      > significantly...
      > but... HOW do i get it into my binbuf... using binbuf_text()
      > crashes if I pass a pointer to my XML data.
      >
      -------------- http://www.bek.no/~pcastine/Litter/ --------------
      Peter Castine | ^
      | Litter Power & Litter Bundle for Jitter
      pcastine@gmx.net |
      pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
      4-15@kagi.com | for Max/MSP
      | Extremely cool
      | http://www.dspaudio.com
      | http://www.dspaudio.com/software/software.html
    • Jan 27 2006 | 4:46 pm
      Hi Peter, thanks for your reply.
      > Alternately: if you save your data to a separate file, can you wrap
      > everything up in a Bundle? (At least for Mac OS). There is extra
      > work involved, and obviously the one-big-file approach would be
      > more convenient. But for the user at least it looks like a single
      > file.
      correct me if I'm wrong, but a max patch is already a flat file. my
      intuition tells me that inserting a maxb file into a bundle and then
      telling max to open that bundle wont work, as max won't find the maxb
      file. or am i wrong? an .mxo file is for example a bundle, but
      support for that format had to be programmed inside the max app. I
      need to get my data into the maxb file and not the .mxo file...
      > Idea 1: You might be able to build a work around by encoding, say,
      > 1MB at a time to binbuf_text(). Either using multiple binbufs or
      > filling one, processing it, and clearing it before starting the
      > next MB (sorry, I don't have the API in front of me right now, so
      > I'm not sure exactly how this would work, but you get the idea...)
      yeah, I was considering this as well, but there's one aspect of the
      binbuf_text() method which gives me a really bad (baaad) feeling...
      and that is (from the docs)
      Note: Commas, symbols containing a dollar sign followed by a number
      1-9, and
      semicolons are identified by special pseudo-type constants for you
      when your text is
      binbuf-ized.
      I read that as being the "headache clause"
      to me it looks as though however you manage to get the data into the
      maxb file, it's a kludge. and i'm just not so excited about building
      any kludges into this project. [ is it a dream? a kludge free
      project? ]
      maybe in the future there will be a method for putting arbitrary data
      into a binbuf...
      or even better:
      max documents as media bundles! would be awesome...
      thanks again peter!
      [gruesse aus schallstadt!]
      |K<