[PD] network problem with pd / [list-fifo]

Hans-Christoph Steiner hans at eds.org
Sun Dec 17 23:18:46 CET 2006


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 thread, so there are no guarantees that the [open( command  
will return in any set amount of time.  Its undetermined.  So it  
should output a message when it is ready to play so that open-then- 
play could be handled programmically.

We are also working this out with [hidio].  A thread will probably be  
necessary to build the device list without causing interruptions.  So  
the idea is that you send a [refresh( message, then it replies with a  
[refresh 1( if successful and a [refresh 0( if complete, but  
unsuccessful.

.hc

On Dec 17, 2006, at 1:42 PM, Roman Haefeli wrote:

> 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 emptied again. buffer overruns could be avoided in
> userspace, if these object would output their internal state. it would
> be already quite helpful, if there would be a second outlet, that
> outputs a bang when ever the buffer is completely emptied (like
> [textfile] or [list-drip] and other object do). with this  
> information it
> would be possible to build a patch, that uses maximum bandwidth  
> without
> ever getting dropouts. the above concerns at least [netsend],
> [netserver]/[netclient] (from maxlib) and possibly the objects from
> mrpeach.
>
>
> 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.
>
> roman
> <list-fifo.pd>
> <list-fifo-help.pd>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



------------------------------------------------------------------------

Mistrust authority - promote decentralization.  - the hacker ethic






More information about the Pd-list mailing list