atom feed11 messages in at.iem.pd-listRe: [PD] Best way to deal with many t...
FromSent OnAttachments
B. BogartFeb 20, 2009 8:59 pm 
Roman HaefeliFeb 21, 2009 1:59 am 
cyrille henryFeb 21, 2009 2:51 am 
David DoukhanFeb 21, 2009 4:32 am 
B. BogartFeb 21, 2009 9:52 am 
cyrille henryFeb 21, 2009 12:48 pm 
Mathieu BouchardFeb 21, 2009 3:36 pm 
Jonathan WilkesFeb 21, 2009 6:03 pm 
David DoukhanFeb 22, 2009 5:00 am 
marius schebellaFeb 22, 2009 2:05 pm 
cyrille henryFeb 22, 2009 4:50 pm 
Subject:Re: [PD] Best way to deal with many tables.
From:cyrille henry (cyri@la-kitchen.fr)
Date:Feb 22, 2009 4:50:36 pm
List:at.iem.pd-list

marius schebella a écrit :

cyrille henry wrote:

the best 2D table are probably images. if the 8bits limitation is not a problem, you can store your arrays in 1 (or more) big image (1000x768).

hi, just curios, are you using [pix_set] for that or sig2pix? or an external program.

pix_image to load a static image. or you can draw anything in a frambuffer and use pix_snap.

but this will not replace iemmatrix....

because with pix set the range is bet 0 and 1 and if I wanted to store values bet 0 and 256 I just divide by 256?

you have to divide by 255, not 256.

cyrille

isn't there a size limit of length of the message that is passed between objects?

Gem pass pointer...

Cyrille

marius.

pix_crop + pix_pix2sig to get a row of your image in a table.

Cyrille

B. Bogart a écrit :

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-l@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

_______________________________________________ Pd-l@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

_______________________________________________ Pd-l@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list