Forums > Dev

how to store a buttload

January 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<


January 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


January 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<


Viewing 3 posts - 1 through 3 (of 3 total)