I think you're confusing a pair of details:
# I tried to build an abstraction which remembers its previous state
before closing the patch. I put an array in the abstraction with its "save contents" option checked and saved the state of the abstraction in this array of which name starts with $0- in order to make each table unique. A [loadbang] outputs the values stored in the array.
first, the values don't get stored in the arrays, because to do so you
have to save the abstraction with the modified array. that only works when
you open up each abstraction and press ctrl-s, or if you would send a
pd-abswmem.pd menusave message - which usually works, but with
abstractions makes pd work at 100% cpu and forces me to terminate the
program.
second, each patch has it's own $0 identifier, which will make each
abstraction unique. but if you save the abstraction itself with any stored
value, it is still only one file, which will make all abstractions to open
up with the same stored value. in this case the $0 will be of no help,
because you're not using it.
# And I see the ambiguity. There is only one .pd file for the
abstraction, so, only one file for storing the values of the array. Which abstraction object's array will be saved etc?
you could save each array into it's individual text file, and retrieve it
back later (with the write/read messages, consult all_about_arrays.pd) -
an external file to serve as memory should be the only sollution here. but
then you must make the mechanism which will make each abstraction know
which is its file. I think it would be more confortable to make one table
for a whole patch (that's how I usually work).
this has been a topic in these last days. look the archives / web for
memento, ssad, rradical, these seem to be the main mechanisms for this
kind of operation, and they seem to be very good (I never used them).
Joao