Re: [PD] network maintainance: 18.07.2012 10:00-12:00CEST
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-17 17:46, IEM - network operating center (IOhannes m zmoelnig) wrote: due to a scheduled network maintainance, puredata.info and associated services (including the pd related mailinglists) will be offline tomorrow, wednesday starting at 10:00 (CEST). we hope to be online again within two hours. after a bit more than two hours (thanks to cisco for that), puredata.info (including this list) should be back to normal. a couple of things still have to be fixed, so expect short outages during the next days. sorry for any inconvenience. fgasmdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAG/OMACgkQkX2Xpv6ydvSlyACeIAAGj+byR1XGVl201Q+W4i/q c/kAnRfAlXAVeEwg7mth/Hqow2ZKHk+i =z9Ns -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] network maintainance: 18.07.2012 10:00-12:00CEST
due to a scheduled network maintainance, puredata.info and associated services (including the pd related mailinglists) will be offline tomorrow, wednesday starting at 10:00 (CEST). we hope to be online again within two hours. sorry for the inconvenience. fgasdr IOhannes -- IEM - network operation center mailto:n...@iem.at ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD network problem - pdextended
see i thought that as well but pd starts and will not let me edit a patch issuing sudo ifconfig lo up did not work. i know this is OT, but any tips might help pp Martin Peach [EMAIL PROTECTED] wrote: Mathieu Bouchard wrote: On Fri, 14 Dec 2007, Martin Peach wrote: bigswift wrote: When using pd onsite without a network connection i cannot edit files with pd-extened RC5 on Ubuntu Gutsy. If a ethernet cable is connected i can edit files, but if i am not wired in i cannot make new connections or edit a file. Is there a way to workaround this? Put the files on the same machine your keyboard is connected to? I suggest that you disconnect your keyboard while you make suggestions like this one ;) Just eliminating the obvious, like My computer doesn't work Did you plug it in? Er, never mind ;) Seriously, isn't that a problem with the routing on network interface lo? I had problems like that because a certain version of a DHCP program would take the default as being DHCP on all connections, but no-one runs a DHCP server on lo, and everybody has lo, so it would erase the lo settings every damn time, if you forget to specify a network interface as an argument. I think pd wouldn't even start up if lo wasn't enabled (because there would be no route to the gui). Why would the presence of a connection to some other machine affect anything if no necessary resources are on that machine? Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Patrick Pagano Sound and Light Technologist School of Theatre and Dance University of Florida ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD network problem - pdextended
Hi, Looks like your 'lo' isn't set up correctly on boot, something similar is here: https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/110144 Martin Peach wrote: bigswift wrote: Hi When using pd onsite without a network connection i cannot edit files with pd-extened RC5 on Ubuntu Gutsy. If a ethernet cable is connected i can edit files, but if i am not wired in i cannot make new connections or edit a file. Is there a way to workaround this? Put the files on the same machine your keyboard is connected to? Martin Claude -- http://claudiusmaximus.goto10.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD network problem - pdextended
bigswift wrote: Hi When using pd onsite without a network connection i cannot edit files with pd-extened RC5 on Ubuntu Gutsy. If a ethernet cable is connected i can edit files, but if i am not wired in i cannot make new connections or edit a file. Is there a way to workaround this? Put the files on the same machine your keyboard is connected to? Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD network problem - pdextended
Mathieu Bouchard wrote: On Fri, 14 Dec 2007, Martin Peach wrote: bigswift wrote: When using pd onsite without a network connection i cannot edit files with pd-extened RC5 on Ubuntu Gutsy. If a ethernet cable is connected i can edit files, but if i am not wired in i cannot make new connections or edit a file. Is there a way to workaround this? Put the files on the same machine your keyboard is connected to? I suggest that you disconnect your keyboard while you make suggestions like this one ;) Just eliminating the obvious, like My computer doesn't work Did you plug it in? Er, never mind ;) Seriously, isn't that a problem with the routing on network interface lo? I had problems like that because a certain version of a DHCP program would take the default as being DHCP on all connections, but no-one runs a DHCP server on lo, and everybody has lo, so it would erase the lo settings every damn time, if you forget to specify a network interface as an argument. I think pd wouldn't even start up if lo wasn't enabled (because there would be no route to the gui). Why would the presence of a connection to some other machine affect anything if no necessary resources are on that machine? Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] network
hi list, i'm sending control data to a vline~ object over the network. those are precisely timed messages. i can hear uncontinuous errors in the output, some messages seem to be delayed. when i use OSC the timing is pretty bad. now i use netserver/ netclient and it's getting better, but there are still some discontinuity hearable (in the sampleplaying of the tabread4~ driven by the vline~). i guess i can further optimize by avoiding all other network traffic, but is there another way to get the sheduling tighter? thanks, m. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] network
Max Neupert wrote: hi list, i'm sending control data to a vline~ object over the network. those are precisely timed messages. i can hear uncontinuous errors in the output, some messages seem to be delayed. when i use OSC the timing is pretty bad. now i use netserver/ netclient and it's getting better, but there are still some discontinuity hearable (in the sampleplaying of the tabread4~ driven by the vline~). i guess i can further optimize by avoiding all other network traffic, but is there another way to get the sheduling tighter? I think the best way would be to put some kind of timestamp in the messages and have the receiver hold the received message until the timestamped time occurs. That should get rid of any jitter at the expense of a second or so of delay. Otherwise put the machines as close together as possible (speed of electrons is about 10cm per nanosecond ;)) and have them be the only two machines on the network, using a crossover cable instead of a switch/router. Also disable background network processes like file sharing and NTP. Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] network
I think the best way would be to put some kind of timestamp in the messages and have the receiver hold the received message until the timestamped time occurs. That should get rid of any jitter at the expense of a second or so of delay. In fact that's an interesting point related to OSC. OSC of course supports exactly this -- the use of timestamps for synchronizing data. And yet it's rarely actually used to its full advantage. In both the Pd and Max/MSP implementations there's no way to send data over an OSC connection scheduled for a delayed timestamp. In other words, there's no way to sacrifice a bit of latency for timing precision. However, OSC itself should allow you to do it. I wonder if it would be a good thing to have sendOSC accept another message, such as delaysend or something which allows specifying what time the message should be deployed on the receiver. It would be very useful, for example, for synchronized clocking over multiple clients. Any thoughts? How might the timestamp be most easily specified in Pd? Steve ___ 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]
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
