On Sun, 17 Dec 2006, Roman Haefeli wrote:
netpd's major problem is the occurence of many dropouts in certain
situations. one reason is the way how all (at least all i know) network
related objects in pd handle buffer overruns. when the buffer of a
network object is full, the whole pd processin
On Mon, 2006-12-18 at 13:47 +0100, Frank Barknecht wrote:
> Hallo,
> Roman Haefeli hat gesagt: // Roman Haefeli wrote:
>
> > as a crude solution to limit bandwidth in netpd, i made the attached
> > abstraction [list-fifo]. i am not sure, if it is a suitable name.
> >
> > @frank
> > if you think,
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
> as a crude solution to limit bandwidth in netpd, i made the attached
> abstraction [list-fifo]. i am not sure, if it is a suitable name.
>
> @frank
> if you think, that fits into your list-abs-collection, feel free to
> add/modify it.
T
I like the status message idea a lot. I think that whenever a Pd
object handles something that cannot be handled in one clock tick,
then there needs to be an output to communicate when the process
finishes.
Another example where this would be useful would be with [readsf~].
It uses a
hi all
netpd's major problem is the occurence of many dropouts in certain
situations. one reason is the way how all (at least all i know) network
related objects in pd handle buffer overruns. when the buffer of a
network object is full, the whole pd processing is stopped until the
buffer gets emp
