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
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
Hi,
I am still unable to reproduce it on a simple test patch; however, I've done
the following test.
I run my patch, which is a rather complex patch, made up of a lot of
abstractions, graphical interface, many send~s and receive~s, throw~s and
catch~s, a lot of tables, a few tabread~s and a
Hi again,
Going on with the test that I described in the previous post (included
below), I have tried to send a [set somethingelse( to the [tabread~] before
I resize the table xxx, so that when I do the resize, there isn't any
tabread~ reading from it anymore. But the drop-out happens
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 ...
I'm talking about resizing tables by sending them a [resize( message.
I tried to isolate it in a simple patch but I couldn't reproduce it. But
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
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
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
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! :)
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
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
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
12 matches
Mail list logo
