Pattrstorage, active 1/0, and scripting


    Feb 11 2008 | 8:12 pm
    Yes, I have a lot of questions these days.
    I'm working on something that is going to be instantiating n (100 + )
    patchers, each one of which could be handling 100+ variables
    controlling 6-8 audio engines, and considering the wisdom of managing
    it all in a pattrstorage, and coming across some problems:
    To clarify: each patcher has to contain some variables which define
    its own state (mostly UI stuff) and another, larger set of variables
    controlling the audio engines. (most of these are not used in any one
    patcher, but they all have to be available and writing scripts inside
    those patchers to create or destroy the storage spots to the engines
    would give me, and probably pattrsorage, a stroke.)The goal is to keep
    the variables about itself consistent while changing the data sent out
    with different presets.
    I realize I could make each scripted patcher it's own preset, but then
    in order to not change the state of the other scripted patchers, I
    need to be perpetually storing only parts of a preset, not a whole one
    at once, and this is an annoying amount of work, which certainly does
    not make the best use of ps's sexiness.
    I then thought to have one preset (say #9999) which stored the state
    variables of each patcher, and using the active attribute to 'turn
    off' those particular variables, so I could change presets without
    changing the internal states. However, the grim reality seems to be
    that setting active to 0 is actually identical to sending a setall
    message to a variable, and writing all of that to the storage file.
    If I have 100 buttons with 10 state variables each, I thus have 1000
    entries in my storage file I essentially never use. Not only does
    this offend my sense of elegance, but tests I have run are showing
    that I'm having hangs while reading & writing a file with all those
    entries, not conunting all the other kazillion variables. (Yes, it
    needs to be in one file).
    First of all, am I doing something wrong? Or is it expected behavior
    that all that data gets written to the file?
    Also, whenever I script in a new patcher, and a new slot to go with
    it, whatever slots are currently filled transfer their data to the new
    slot, if it needs it or not, meaning I have even more redundant
    information in the file. I can't find it, but is there a way to
    create an "empty" slot when scripting?
    I hope this is clear, as it would take a while to extract my example
    patch, but I will if my prose has let everyone who has bothered to red
    to the end confused.
    thanks as always,
    M

    • Feb 12 2008 | 11:06 am
      Some of this is deliberate; the thinking was that your decision to de-activate a particular entry may be more fleeting than the data. We back the data up for safekeeping.
      I guess what you want is to be able to store presets without storing the data for every object, or at least some way to remove the data for a particular object, thus removing its 'entry' in the save file.
      This doesn't currently exist for pattrstorage, and I'm not sure if or when it will. You could, however, trim your files manually or with a script (Ruby is my weapon of choice here) after they've been created.
      Essentially, the hierarchical pattrstorage support (pattrstorage controlling the preset state of other pattrstorage objects) was intended to eliminate precisely this situation, where you need to store thousands of individual values. As you've determined, for whatever reason, to not use this very powerful mechanism, you're probably going to have to find some annoying workarounds for the issues you're seeing.
      Jeremy
    • Feb 19 2008 | 8:15 pm
      for the record, the other main programmer threw together a demo of his
      massive list idea, & while doing it, realized that he was simply
      writing patrstorage in Max, which is what i had been talling them all
      along, and I think I got them over their fear of multiple preset
      files, so all is well in the world.
      Let me know when you're coming to Vienna....
      M
      On Feb 12, 2008, at 12:06, Jeremy Bernstein wrote:
      >
      > Some of this is deliberate; the thinking was that your decision to
      > de-activate a particular entry may be more fleeting than the data.
      > We back the data up for safekeeping.
      >
      > I guess what you want is to be able to store presets without storing
      > the data for every object, or at least some way to remove the data
      > for a particular object, thus removing its 'entry' in the save file.
      >
      > This doesn't currently exist for pattrstorage, and I'm not sure if
      > or when it will. You could, however, trim your files manually or
      > with a script (Ruby is my weapon of choice here) after they've been
      > created.
      >
      > Essentially, the hierarchical pattrstorage support (pattrstorage
      > controlling the preset state of other pattrstorage objects) was
      > intended to eliminate precisely this situation, where you need to
      > store thousands of individual values. As you've determined, for
      > whatever reason, to not use this very powerful mechanism, you're
      > probably going to have to find some annoying workarounds for the
      > issues you're seeing.
      >
      > Jeremy