Hi all,
Well, it might be simpler to store a pointer to the t_array instead of one to the actual vector (a_vec) in the DSP routines. That way, resizing or swapping vectors could happen without re-sorting DSP, but you'd still have to re-sort ig a "t_garray" got deleted or renamed. The cost would be one additional pointer chase in each of the tabread~, tabwrite~, etc., operations.
I've almost finished my work of redesigning the garray/array business (to unify it with arrays in "structs") and hope to check it in today...
cheers Miller
On Fri, Nov 26, 2004 at 02:46:11PM +0100, Tim Blechmann wrote:
hi miller, hi devs
Hmm, and on that subject, I'm making changes in garray for 0.39 that might point to a different approach to using arrays in DSP, not sure yet. I'm trying to unify "regular" (named) arrays with the ones that can appear in"scalars"... which is in turn necessary for me to make any more progress on the "data" aspect of Pd...
working on the threaded soundfiler again, i'm investigating possibilities to update pointers to g_arrays that are ->usedindsp ...
since the current implementation using canvas_update_dsp() possibly recompiles the dsp chain (is this correct?), i thought of a way to store the pointers to the pointers to the array in garray_getfloatarray() in struct t_array ... after the position of the array in memory changed, it's possible to update all these pointers ...
miller ... since you are also planing to work on arrays in dsp, i'm curious if you already thought of a different solution for such a problem ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev