Hi,
I am getting dsp drop-outs when I resize a table (say a size of 20 or
so) if a tabread~ object exists reading from that table, even if I am not
listening to the output of the tabread~.
Even if the tabread~ is in a switch~ed off subpatch/abstraction.
Does PD recompute the whole DSP chain
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 cou
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 allthesam
> 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.
>> 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 ab
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 tab
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 derefe
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" oppo
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-realt
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
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
13 matches
Mail list logo