[PD] abstractions which have their own memory

João Miguel Pais jmmmpais at googlemail.com
Tue Jul 4 17:47:39 CEST 2006


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




More information about the Pd-list mailing list