what is the maximum size blob i can store in a pattr?
I'd like to store some state in a pattr. Specifically a pattr with @parameter_enable 1 set. More specifically, I would like to store a LOT of state, maybe up to 100KB. However, When I attempt to test pattr by saving and loading strings within it, inspecting the Parameter object inspector, I notice that, at least as far as that inspector goes, no more than 2048 characters are retrievable. Is this an upper limit on pattr blobs? Or just the inspector? Can it be extended at all, or do I need to resort to old-school methods such as saving to a text file?
ive been storing around 3000 characters as far as i remember . cant check my patch to confirm , but it was around it ! . and i also think that i could not see all of them with pattr ui
Thanks KrisW.
I wrote a small JS to test it. The limit is 32767 chars.
var statestring ="a";
for (var i = 0; i < 12; i++) {
statestring = statestring + statestring;
}
function dumpstate() {
var pattrwithstate = this.patcher.getnamed("JS_STATE_TEST");
post("saved", statestring.length, "charsn");
}
function loadstate() {
var pattrwithstate = this.patcher.getnamed("JS_STATE_TEST");
var loadedstatestring = pattrwithstate.getvalueof()[0];
post("loaded", loadedstatestring.length, "chars n");
}The output of that script, if send a "dumpstate" message, is js: saved 65536 chars.
Type in "loadstate" and you get js: loaded 32767 chars
Let me say that again for posterity using nice searchable keywords.
The maximum size of blob storage in a pattr is 32767 chars, or 32KB -1
You could potentially extend this by breaking the data up into a bunch of symbols. Each symbol can be ATOM_MAX_STRLEN (32768) long, including the terminating '' character (so ATOM_MAX_STRLEN-1 useful characters). I don't remember offhand what the max number of atoms is, but it's at least in the thousands.
Even better, depending on your data, might be to format your state in a dictionary and store the dictionary object in the pattr.
Hope that helps, Jeremy
Thanks, Jeremy. But if I break my blob up in to atoms, can it be stored in the .amxd paramater data? I mean, a normal pattr, yes, but the UI for parameter_enabled stuff seems to only allow Live data types - Float, Int, Enum, Blob. Or am I missing something?
Hi Jeremy,
Sorry to take to so long to respond after your generosity - Of course, when I finally had the chance to give your suggestion the attention it deserved, the forums were then down for upgrade.
Anyway, I've been avoiding dictionaries per se because, as far as I can tell, they get weird really rapidly if you try and store, e.g. nested dictionaries inside them from JS (var foo = new Dict("foo"); foo.set("bar", {baz:5}); gives me a dictionary that looks like this: {"bar": ["jsobject", 1234123]}, That's not really ideal, so I'd rather make do with my own perfectly good JS, which also has the added bonus of working outside Max with less modification.
In any case, I gave the persistence thing a try, but I ran into more issues with persisting a dictionary in a live device. I mean, I 'd rather have dicts provide some nice lightweight local structured storage per-device, but they are implicated in the strange world of Max's global namespace, so it's not really obvious to me how they are supposed to be persisted across sessions but not between devices, if you understand what I mean. So I made a M4L device that tries "local names" (i.e. with triple-dash syntax), "global" (i.e. normal) names and no names at all, to see which gives me device-local persistence. The answer appears to be none. Attached is a max device which demonstrates this. Put two copies of it in your live set and see if you can get state to persist across sessions, but not between both devices. I suspect the answer is some combination of un-named dicts and pattrs and such. But at that point I am thinking that good-ol' JSON is a simpler.
Are there any benefits to using dicts to persist state? Can I squeeze more data in or something because it will pack the data better? Or is it just cooler/more accessible to non-JS objects?
Cool. That worked well. Er, looks if the system accepts .zip, but not .amxd. Now I am in the weird siutation where I can't directly upload code samples for YOUR software, but I can upload malware, viruses, bomb plans, stuxnet derivatives etc, just so long as I compress them first. I'm not sure that this particular "security restriction" makes me feel more secure ;)