what is the maximum size blob i can store in a pattr?

    parkingsun
    Apr 05 2013 | 7:20 pm
    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?
    • KrisW
      Apr 05 2013 | 7:29 pm
      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
    • parkingsun
      Apr 05 2013 | 8:40 pm
      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
    • Jeremy
      Apr 06 2013 | 11:13 am
      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
    • parkingsun
      Apr 14 2013 | 9:23 pm
      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?
    • Jeremy
      Apr 15 2013 | 1:43 pm
      A Blob is simply "non-automatable, anonymous parameter data". It can be whatever you want, as long as it doesn't exceed size limitations. Here's an example of using dictionaries, which I suppose is the most appropriate for your purposes.
      Best, Jeremy
    • parkingsun
      May 13 2013 | 8:36 pm
      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?
    • parkingsun
      May 13 2013 | 8:41 pm
      HAHAH! the new forum doesn't allow amxd attchments. Let me see if I  can CUNNINGLY FOOL YOUR SYSTEM by ZIPPING THE FILE.
    • parkingsun
      May 13 2013 | 8:44 pm
      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 ;)