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
-- tim@klingt.org 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