11 messages in at.iem.pd-listRe: [PD] Best way to deal with many t...| From | Sent On | Attachments |
|---|---|---|
| B. Bogart | Feb 20, 2009 8:59 pm | |
| Roman Haefeli | Feb 21, 2009 1:59 am | |
| cyrille henry | Feb 21, 2009 2:51 am | |
| David Doukhan | Feb 21, 2009 4:32 am | |
| B. Bogart | Feb 21, 2009 9:52 am | |
| cyrille henry | Feb 21, 2009 12:48 pm | |
| Mathieu Bouchard | Feb 21, 2009 3:36 pm | |
| Jonathan Wilkes | Feb 21, 2009 6:03 pm | |
| David Doukhan | Feb 22, 2009 5:00 am | |
| marius schebella | Feb 22, 2009 2:05 pm | |
| cyrille henry | Feb 22, 2009 4:50 pm |
| Subject: | Re: [PD] Best way to deal with many tables. | |
|---|---|---|
| From: | David Doukhan (davi...@gmail.com) | |
| Date: | Feb 22, 2009 5:00:14 am | |
| List: | at.iem.pd-list | |
2009/2/21 B. Bogart <be...@ekran.org>:
Thanks all for your comments. David, How fast was your python code to generate the tables? Seems like it would be about the same issues as dynamic patching.
The python code does not generate the tables: it generates a patch. IE: suppose you wrote a patch that load a piece of data into an array: this is your atomic component. Then, with the python script (or any language you like), you generate a patch storing all those atomic components. The goal is just to avoid putting a huge number of components on a patch yourself, since it could be automatized. This is not a dynamic solution: once the patch has been generated, it won't change until you generate it again. So concerning the performances (speed, etc...), they will be the same as non dynamic solution. I don't know if it corresponds to what you're looking for, if it seems to suit your needs, I can try to explain better.
-- David Doukhan
_______________________________________________
Pd-l...@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list