Re: [PD] network problem with pd / [list-fifo]
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. Thanks a lot, this can be a very useful patch. I added it to the [list]-abs on CVS with some small changes/extensions: Internally it uses the new [list-extend] abstraction now to build lists from incoming messages. I added a clear method to the first inlet to empty the FIFO, I changed the default delimiter to the empty symbol, and added the possibility to set the delimiter with an abstraction argument as well like [list-fifo my-l33t-del1m17er] Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] network problem with pd / [list-fifo]
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, that fits into your list-abs-collection, feel free to add/modify it. Thanks a lot, this can be a very useful patch. I added it to the [list]-abs on CVS with some small changes/extensions: Internally it uses the new [list-extend] abstraction now to build lists from incoming messages. I added a clear method to the first inlet to empty the FIFO, I changed the default delimiter to the empty symbol, and added the possibility to set the delimiter with an abstraction argument as well like [list-fifo my-l33t-del1m17er] wow.. cool! ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] network problem with pd / [list-fifo]
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 processing is stopped until the buffer gets emptied again. Pd doesn't handle all of its sockets like that. There's one special socket that handles it differently, and it's the socket that talks to the GUI process. In Pd 0.38, Miller added a bunch of special code in s_inter.c that allows it to do nonblocking writes and causes it to replace the output buffer by a bigger one. The problems that I see with that are: 1. there's no way to limit the size of the output buffer. If the other side of the connection doesn't respond, the sending buffer just inflates quickly. I've seen it happen that a bug in the sender causes it to try to send so fast that it ate memory like an infinite recursion or a forkbomb. 2. That operation is not realtime-safe (but still it's much closer to being so than just blocking...) 3. It's only usable by the GUI socket and never by [netsend]. 4. While that buffer together with t_guiqueue allow GUI updates to be delayed for as long as necessary, it doesn't solve the problem that it can send information that is already outdated and redundant. This can be important in preventing problem #1 for a very heavy GUI. DesireData has had this problem essentially dealt with since a long time, but it lacks some fine tuning to get more robust. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] network problem with pd / [list-fifo]
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 #N canvas 546 60 474 380 10; #X obj 138 129 list append; #X obj 139 101 list; #X obj 139 79 t b l; #X obj 22 182 list split 1; #X obj 22 160 list append; #X obj 22 206 sel [delim]; #X obj 22 134 until; #X obj 139 57 list append [delim]; #X obj 94 278 list append; #X obj 94 228 t b l; #X obj 94 256 list; #X obj 22 305 list; #X obj 22 231 t b b; #X obj 22 6 inlet trigger; #X obj 139 5 inlet list; #X obj 303 6 inlet delimiter; #X obj 303 28 route symbol; #X obj 22 329 outlet; #X obj 239 332 outlet; #X obj 180 171 b; #X connect 0 0 1 1; #X connect 0 0 4 1; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 2 1 0 1; #X connect 3 0 5 0; #X connect 3 1 4 1; #X connect 3 1 1 1; #X connect 3 2 18 0; #X connect 3 2 19 0; #X connect 4 0 3 0; #X connect 5 0 12 0; #X connect 5 1 9 0; #X connect 6 0 4 0; #X connect 7 0 2 0; #X connect 8 0 10 1; #X connect 8 0 11 1; #X connect 9 0 10 0; #X connect 9 1 8 1; #X connect 10 0 8 0; #X connect 11 0 17 0; #X connect 12 0 11 0; #X connect 12 1 10 1; #X connect 12 1 8 1; #X connect 12 1 6 1; #X connect 13 0 6 0; #X connect 14 0 7 0; #X connect 15 0 16 0; #X connect 16 0 7 1; #X connect 16 0 5 1; #X connect 19 0 6 1; #N canvas 131 63 657 285 10; #X obj 18 196 print; #X obj 76 166 print EOF; #X obj 18 12 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 47 32 eins due trois four; #X msg 56 52 1 2 3 4 5; #X symbolatom 69 73 10 0 0 0 - - -; #X floatatom 82 90 5 0 0 0 - - -; #X text 204 65 [list-fifo] keeps back incoming messages \, so that they can be outputted afterwards.; #X text 202 150 [list-fifo] can be used to limit the number of messages passing during a certain time (might be usefull to limit the used network bandwidth).; #X symbolatom 114 117 10 0 0 0 - - -; #X text 194 116 - change delimiter symbol; #X text 202 215 !! PROBLEM !!; #X text 42 11 - trigger output; #X obj 18 137 list-fifo; #X text 203 233 when a message contains the delimiter symbol \, it is falsely split into two parts.; #X connect 2 0 13 0; #X connect 3 0 13 1; #X connect 4 0 13 1; #X connect 5 0 13 1; #X connect 6 0 13 1; #X connect 9 0 13 2; #X connect 13 0 0 0; #X connect 13 1 1 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
