Resizing large memory objects in a real-time thread can block as the OS pages other memory out to disk... so the operation is never safe unless done in a separate thread. This would be a major change, and would move in the direction of making Pd harder to maintain in the long term.
Fixing the tabread~ object to do a double dereference would fix the problem in 99% of cases... which is just the wrong thing to do if you want to be able to use software on stage :) cheers Miller On Sun, Aug 19, 2007 at 02:27:43PM +0200, Tim Blechmann wrote: > On Sun, 2007-08-19 at 13:53 +0200, Matteo Sisti Sette wrote: > > >> Does PD recompute the whole DSP chain whenever a table (with one or > > more > > >> tabread~ reading from it) is resized? > > > > > >yes, the dsp chain is recreated ... > > > > Why does it need to recompute the dsp graph? > > > > I know nothing about pd internals, but (or should I say "so") I really > > can't > > see the reason for recomputing the dsp graph after resizing a table. > > don't ask me, ask miller (imho, this is one of the big design faults of > pd). > i can only guess, that it is done due to performance reasons ... it > saves one pointer dereferencing. this is of course not a real > explanation, as it is perfectly possible to keep track of the pointers > in the dsp chain ... neither is it that expensive to do an additional > pointer dereferencing ... > > > It seems it does not even recompute it when you send a > > [set ...( message to > > a tabread~ (at least I get no dropouts)... why do it when you resize > > a > > table? > > that is the other direction ... when objects are bound to the table, > then they can just call garray_getfloatarray ... if tables change, > garray_getfloatarray has to be called from all objects, that are bound > to this table ... > > cheers, tim > > -- > [EMAIL PROTECTED] ICQ: 96771783 > http://tim.klingt.org > > I had nothing to offer anybody except my own confusion > Jack Kerouac > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list