Forums > MaxMSP

Pattrstorage, active 1/0, and scripting

February 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


February 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


February 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


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