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. 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?
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Vivi i MONDIALI di ATLETICA di TOKYO da protagonista. Compra on line i prodotti ufficiali della Nazionale Italiana FIDAL. Vestiti di azzurro Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6907&d=19-8
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
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
On Sun, 19 Aug 2007, Miller Puckette wrote:
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 :)
Obviously, fixing 99% of the problem is the wrong thing to do! :)
It's much better to fix 0% of the problem! :)
bye :)
:)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Well, me, I think it's better to preallocate the table objects to a size at least as large as will be needed, in advance.
cheers M
On Sun, Aug 19, 2007 at 02:34:22PM -0400, Mathieu Bouchard wrote:
On Sun, 19 Aug 2007, Miller Puckette wrote:
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 :)
Obviously, fixing 99% of the problem is the wrong thing to do! :)
It's much better to fix 0% of the problem! :)
bye :)
:)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801, Montr?al QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 19 Aug 2007, Miller Puckette wrote:
Well, me, I think it's better to preallocate the table objects to a size at least as large as will be needed, in advance.
Most language implementations nowadays distinguish between "capacity" and "size", which is a kind of "physical vs logical" opposition (in old computer jargon). That is, from a usage point of view, the array may look small, but it has a guarantee to be able to grow forward and/or grow back by certain amounts. That way an array can signify the actual size of data while preallocating all that will ever be needed; though in almost all cases this is done for other reasons instead.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Sun, 2007-08-19 at 11:09 -0700, Miller Puckette wrote:
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.
what's the problem with using a separate thread for non-realtime operations?
This would be a major change, and would move in the direction of making Pd harder to maintain in the long term.
if the overall architecture is powerful enough, this shouldn't really be a problem ... the threaded buffer resizing of nova is less than 40 lines of code :)
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 :)
aehm ... i'm curious about the other 1% ... from my understanding, the current hierarchy (object->memory) would just be extended to (object->buffer->memory), this indirection should give you another level of abstraction, that can easily be used for error handling ... if i'm missing something here, please let me know, as the whole buffer concept of nova is based on this indirection ...
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
On Mon, 20 Aug 2007, Tim Blechmann wrote:
On Sun, 2007-08-19 at 11:09 -0700, Miller Puckette wrote:
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.
what's the problem with using a separate thread for non-realtime operations?
Because those threads are woven by illegal Mexican immigrants who steal the jobs of citizens of California, that's why!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Aug 22, 2007, at 8:25 AM, Mathieu Bouchard wrote:
On Mon, 20 Aug 2007, Tim Blechmann wrote:
On Sun, 2007-08-19 at 11:09 -0700, Miller Puckette wrote:
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.
what's the problem with using a separate thread for non-realtime operations?
Because those threads are woven by illegal Mexican immigrants who
steal the jobs of citizens of California, that's why!
Actually, the white people in California don't want to hire white
people anymore since Mexicans work much harder. The California
economy would collapse without illegal immigrants, therefore nothing
changes...
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC
Canada_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers