what I did in such situation was to generate pd patch using a python script. Using that method, all the arrays were stored in memory, and could be accessed dynamically by the other components through their names.
2009/2/21 B. Bogart <b...@ekran.org>: > Hey all. > > I've managed to get my patches to use less objects, and more messages. > > Problem I have now is storing data in an organized way. > > Basically the system I'm working on needs to store the RGB hists of many > images (10,000 ideally, RAM permitting). RGB hists are concatenated into > tables of 768 elements each. > > What is the best way to deal with this number of tables? There are the > usual thoughts of using dynamic patching and such, but really I'd like a > more elegant solution. > > Has anyone worked on something like a multi-table or nested table? > > I could put everything in one giant table, but each chunk needs to be a > list in the end and it seems to be iterating over a section of the table > to dump it as a list would be a lot slower than using [tabdump]. > > Just wondering if anyone has any suggestions. > > I've already mentioned my wish to have a generic storage system (similar > to data-structures but independent of any graphical representation) namely: > > tables of floats (done), tables of symbols, and most importantly tables > of tables! > > .b. > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- David Doukhan _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list