Hi,
I tested Pd Vanilla 0.43 for just a couple of days (this was some weeks ago) and I found enough show-stopper regressions that I had to immediately revert to version 0.42.5.
Version 0.43 still isn't mature enough to be used for purposes other than testing it. It should not be considered as the recommended release for "everyday use"; and most important, until it is stable, bug fixes should be still released for version 0.42. I am especially worried about this last thing, as now for example I have to choose between a version that can't broadcast UDP packets on Linux (0.42.5) and a version where the GUI may stop responding at any time (0.43.0).
Here are three bugs that make it unusable, all of them are regressions: bug 3298989: suddenly all the gui objects of a certain type (e.g. all sliders) stop responding bug 3273884: mouse wheel scrolling doesn't work (it scrolls all the way down and all the way up in a single "step") bug 3273848: editing an object box is painful. Depending on where exactly you click, you may be unable to reach the last character (even with the right arrow key); you have to click on it several times until you are lucky.
Note that this is not meant as criticism to the great effort that has been done to write Pd 0.43; if I am criticizing anything at all it is the decision to release it as a stable release superseding 0.42.5. It's just too soon.
I understand that the more people download and use it, the sooner these bugs can be detected and fixed and the sooner PD 0.43 will be stable. But if testing has to be encouraged, it must be done in a fair way. People who are not downloading Pd for the sake of testing it, and who need to get the most stable version, should be aware that 0.43 is _not_ the version they should download.
Cheers, m.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/08/2011 02:14 PM, Matteo Sisti Sette wrote:
i switched to Pd-0.43 in a few "external" production environments (installations that are not only handled by me, that is), and use it exclusively on my "own" machines.
i guess you are aware that not being able to "broadcast UDP packets" is not a bug at all, it's simply a missing feature.
fmgasdr IOhannes
On May 8, 2011, at 8:28 AM, IOhannes m zmölnig wrote:
I've also switched all my development and testing activity to 0.43,
but still use 0.42.5 for teaching. But I'm also on Ubuntu 10.10 and
Mac OS X 10.5, so I'm not quick to upgrade. I think Miller uses 0.43
now too, but I could be wrong. If you are interested in continued
development on 0.42.5, I think Ico has done some with pd-l2ork.
.hc
"Making boring techno music is really easy with modern tools, but with
live coding, boring techno is much harder." - Chris McCormick
On 05/08/2011 02:28 PM, IOhannes m zmölnig wrote:
i guess you are aware that not being able to "broadcast UDP packets" is not a bug at all, it's simply a missing feature.
No, I was not aware of that. Is it really? On windows, you can broadcast UDP packets with a [netsend 1] by sending it a "connect" message with an IP broadcast address, such as 255.255.255.255 or x.x.x.255 (where x.x.x is the local network address) which are the standard IP addresses that are reserved for broadcast.
On linux, you get a "permission denied" message if you do that and it does not connect nor send packets. I seem to remember that someone told me that in the Linux those addresses had been disabled (don't know why), that is, that it had been possible to use them in past versions.
I thought a broadcast address was just an IP address like any other, and I thought the operating system's network protocol stack took care of broadcasting the packets that are addressed to that address. I didn't know there was any need for a "feature" to implement it. That's why I called it a bug. The "permission denied" message made me think that the reason it didn't work was that Pd wasn't doing all it had to do to get the permission to do the broadcasting, or something like that...
On 10/05/11 12:10 PM, Matteo Sisti Sette wrote:
I don't have any trouble here with [udpsend] and debian lenny.
Any time you get permission denied it's up to you to set the permissions. (If a program could do that, why have permissions at all?) Try running as root and see if it changes.
Martin
On 05/10/2011 06:56 PM, Martin wrote:
I don't have any trouble here with [udpsend] and debian lenny.
I don't have any trouble with [udpsend] either. It's [netsend 1] that can't broadcast (neither in Pd Vanilla 0.42.5 nor Pd Extended 0.42.5)
Any time you get permission denied it's up to you to set the permissions. (If a program could do that, why have permissions at all?)
That sounds very reasonable, but then how comes that [udpsend] can broadcast packets and [netsend 1] can't (on the same system, same machine, I've tried both right now)?
My guess is that either A) [netsend 1] is doing something wrong, trying to do something that is not really necessary and that requires some permissions that the program doesn't have B) it is printing a wrong error message and the failure is not really due to a denied permission.
On 10/05/11 01:40 PM, Matteo Sisti Sette wrote:
OK I see now. [udpsend] has this in it right after the socket is created:
/* Based on zmoelnig's patch 2221504: Enable sending of broadcast messages (if hostname is a broadcast address)*/ #ifdef SO_BROADCAST if( 0 != setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, (const void *)&broadcast, sizeof(broadcast))) { udpsend_sock_err(x, "couldn't switch to broadcast mode"); } #endif /* SO_BROADCAST */
...and broadcast is just an int: int broadcast = 1;/* nonzero is true */
I guess if something like that were to be added to the netsend_connect function it would work.
Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-05-10 21:00, Martin wrote:
I guess if something like that were to be added to the netsend_connect function it would work.
sure, and this has already been added to [netsend]. however, it's only available in Pd>=0.43 (or so).
my point is rather, that i don't see why not being able to broadcast should be considered a bug: nobody claimed that this object can do broadcast at all. i totally agree that it is a desirable feature, but so are IPv6 support and tea making facilities.
fgmasdr IOhannes
On Wed, 11 May 2011 09:36:49 +0200 IOhannes m zmoelnig zmoelnig@iem.at wrote:
It's a regression. There's probably a good reason for removing it, however it did do this at one time, and IMO it was useful.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-05-11 11:38, Andy Farnell wrote:
its getting weirder and weirder. looking from the code, Pd-0.43 does support broadcast. doing a quick check (using the debian packages), i can confirm that. i also read matteo's remark, he says that 0.43 has broadcast abilities, whereas 0.42 has not ("I have to choose between a version that can't broadcast UDP packets on Linux (0.42.5) and a version where the GUI may stop responding at any time (0.43.0).")
matteo asked for continued maintainance of 0.42, so that bugs in 0.42 still get fixed. my interpretation was, that he would like to have the "bug in 0.42 that prohibits [netsend] from using broadcast" fixed. my anser to that is, that i (not being the maintainer, so my view is of limited use) don't consider this a bug but rather a feature, and i don't see a point in adding new features to an old release.
i hope this makes it somewhat clearer.
fg asdrm IOhannes
On Wed, 11 May 2011 11:56:34 +0200 IOhannes m zmoelnig zmoelnig@iem.at wrote:
That does make it clearer.
I am still on 0.42 and had that embarrassing (should know better because it's happened before) lecture where I try to use UDP broadcast and it doesn't work for anyone.
It did work in 0.39 and I thought it was permanently dropped, but I guess its back in 0.43. Welcome back net broadcast!! (very useful for teaching where you use dynamic patching with a group).
i don't see a point in adding new features to an old release.
Me neither. I will wait for the GUI glitches to go away and move up to 0.43, hopefully soon.
Andy
On 05/11/2011 12:15 PM, Andy Farnell wrote:
i don't see a point in adding new features to an old release.
Me neither.
I wouldn't either, if the new release was usable.
I will wait for the GUI glitches to go away and move up to 0.43, hopefully soon.
Hopefully.
By the way now just out of curiosity, does anybody know way the feature had been dropped (on Linux) in the first place?
Or you can use disis_netsend external which is practically identical to netsend except it provides broadcast support and a few additional features and improvements. Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Andy Farnell padawan12@obiwannabe.co.uk wrote:
On Wed, 11 May 2011 09:36:49 +0200 IOhannes m zmoelnig zmoelnig@iem.at wrote: > my point is rather, that i don't see why not being able to broadcast > should be considered a bug: nobody claimed that this object can do > broadcast at all. It's a regression. There's probably a good reason for removing it, however it did do this at one time, and IMO it was useful. -- Andy Farnell padawan12@obiwannabe.co.uk_____________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,I would like to know whether there are any fixes to the current oddities regarding netsend/netreceive usage and GUI updates. When receiving massive OSC data from other laptops, our central patch gets frozen (only the GUI, it still works but it is unusable). This is a rather serious bug which prevents absolutely pd networking... Ivica's seems disis_netsend to solve it rather well, but it's only for linux. Any plans to incorporate such fixes into the canonical version?Thanks in advance!Josep M
Quoting Jeppi Jeppi jeppiot@hotmail.com:
Those externals should work on all versions of Pd as they in and of
themselves are not linux-specific.
HTH
Best wishes,
Ico
Hello, IMHE, netsend works perfectly in Linux, OSX and Windows, the only thing to keep in mind is the ip of the computer to control and call the variables are equal, they are sent and those received.
BR
José 2011/8/1 ico@vt.edu
Hi, me again, IMHE, freezes when doing something wrong ... ie error in the ip or send a variable that does not exist, generally functions well, now, you could try with mr peach osc.
José
El 1 de agosto de 2011 15:25, José Luis Santorcuato Tapia < santorcuato76@gmail.com> escribió:
Deffinitely having the GUI frozen after a while shouldn't happen...I don't get any error, it just freezes after some network activity.I use a number of network objects, besides netsend (udpreceive, mr peach osc objects...). I whish I could track/debug what's the cause :( Thanks anyway...!Josep M
Date: Mon, 1 Aug 2011 15:25:30 -0400 Subject: Re: [PD] netsend/netreceive + GUI bug From: santorcuato76@gmail.com To: ico@vt.edu CC: jeppiot@hotmail.com; pd-list@iem.at
Hello, IMHE, netsend works perfectly in Linux, OSX and Windows, the only thing to keep in mind is the ip of the computer to control and call the variables are equal, they are sent and those received.
BR
José 2011/8/1 ico@vt.edu
Quoting Jeppi Jeppi jeppiot@hotmail.com:
Hi,I would like to know whether there are any fixes to the current oddities regarding netsend/netreceive usage and GUI updates. When receiving massive OSC data from other laptops, our central patch gets frozen (only the GUI, it still works but it is unusable).
This is a rather serious bug which prevents absolutely pd networking...
Ivica's seems disis_netsend to solve it rather well, but it's only for linux. Any plans to incorporate such fixes into the canonical version?Thanks in advance!Josep M
Those externals should work on all versions of Pd as they in and of themselves are not linux-specific.
HTH
Best wishes,
Ico
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello, IMHE, netsend works perfectly in Linux, OSX and Windows, the only thing to keep in mind is the ip of the computer to control and call the variables are equal, they are sent and those received.
BR
José
This is however not the case whenever you have a high throughput traffic that arrives form various sources at unexpected intervals as the netreceive sends out its message whenever it receives it rather than waiting for the scheduler interrupt which means when that message lands in the middle of another tcl/tk message that is currently being parsed to be sent out to gui (something that commonly is unlikely to take place when the throughput is low but becomes increasingly more likely as the network traffic increases), you end up with garbage output that results in syntax error on the tcl/tk side and thus tcl/tk becomes unresponsive. This is best observed if you monitor pd->tcl/tk activity with debugger on.
Best wishes,
Ico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-02 22:44, Ivica Ico Bukvic wrote:
This is however not the case whenever you have a high throughput traffic that arrives form various sources at unexpected intervals as the netreceive sends out its message whenever it receives it rather than waiting for the scheduler interrupt which means when that message lands in the middle of another tcl/tk message that is currently being parsed to be sent out to gui (something that commonly is unlikely to take place when the throughput is low but becomes increasingly more likely as the network traffic increases), you end up with garbage output that results in syntax error on the tcl/tk side and thus tcl/tk becomes unresponsive. This is best observed if you monitor pd->tcl/tk activity with debugger on.
hmm, i don't know where you get this idea from, but to me, the code of Pd's networking infrastructure looks, as if a) all incoming traffic was polled for in the main thread b) all output of this traffic (to the Pd-patch) was propery protected by sys_lock()
this basically contradicts your claims of network data being asynchronously fed into Pd's messaging cycle.
of course there might be some bugs in the code, but i rather doubt that.
fgmasdr IOhannes
PS: just for clarity: i'm talking about the [netreceive] object in Pd-vanilla; things might be different in Pd-extended and other networking objects. e.g. iemnet will receive the data asynchronously, but then will pass it to Pd synchronously.
I am honestly not that familiar with this low-level aspect of pd. What I am however aware of is that the poll function responsible for receiving message (meaning when it arrives at the socket) inside netreceive immediately dispatches it to pd and its polling is linked not to pd's main loop but to the moment when the socket has received a packet which appears to be a part of any basic network socket example code available online and as far as I can see, I did not notice any relationship between its polling intervals and Pd's main loop.
FWIW, The only difference in my implementation is that the received messages are forwarded to pd via clock_delay(0) which has fixed all such occurrences inside L2Ork which is quite network traffic heavy, and apparently has resolved problems for others as well.
Best wishes,
Ico
If you are indeed talking about vanilla netsend and netreceive, the poll function is called during pd's main loop, not when something arrives at the socket. In x_net.c : sys_addpollfn(sockfd, (t_fdpollfn)socketreceiver_read, y); socketreceiver_read is in s_inter.c: void socketreceiver_read(t_socketreceiver *x, int fd) sys_addpollfunction schedules the function to be called each pass through Pd's main loop.
Martin
If you are indeed talking about vanilla netsend and netreceive, the poll function is called during pd's main loop, not when something arrives at the socket. In x_net.c : sys_addpollfn(sockfd, (t_fdpollfn)socketreceiver_read, y); socketreceiver_read is in s_inter.c: void socketreceiver_read(t_socketreceiver *x, int fd) sys_addpollfunction schedules the function to be called each pass through Pd's main loop.
Martin
If that is the case, then it seems the bug lies elsewhere but is there nonetheless. The clock_delay workaround has fixed this in pd-l2ork permanently and I am yet to experience gui freeze that has been plaguing our setup way too often before the said workaround.
Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.)
I haven't recreated the situation myself yet, but will do that at some point to try to get a better idea.
At any rate, it's likely that incoming net traffic is also getting dropped - not a good scenario. Ideally there should be a some way for Pd to sense that so that the patch could send out requests to slow the flow down before it starts dropping packets.
In the meantime, a possible workaround: send occasional pings to the receiving Pd, hav ethe Pd patch echo the pings back to tne sending patch, and have the sending patch not allow more than a certain number of other messages go out between pings.
cheers Miller
On Sun, Aug 07, 2011 at 11:56:45AM -0400, Ivica Ico Bukvic wrote:
On Aug 7, 2011, at 5:19 PM, Mathieu Bouchard wrote:
What would it take to convince you to port your DD escaping code to Pd
0.43? :-D :-D :-D
.hc
Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith
Speaking of workarounds what is wrong with clock_delay(0) implementation of disis_ netreceive when it uses existing facilities, has no noticeable overhead, does not drop packets our crash GUI, and is very easy to implement?
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Jeppi Jeppi jeppiot@hotmail.com wrote:
That's exactly what happens, some minutes after clients start sending massive OSC stuff to my server, its GUI freezes but PD works ok and I can operate with sliders and number boxes, though I can't see anything.
Frustrating :)
Josep M
Hmm... I don't have a clear idea of what the scheduling policy or policies should be for incoming and outgoing network traffic. I think I need to figure that out first before starting to tweak netsend/netreceive (and pd~, which could share some code with netsend/receive if I could think things through better.)
cheers Miller
On Mon, Aug 08, 2011 at 12:58:06PM -0400, Ivica Ico Bukvic wrote:
I have no idea if this is a relevant aside, but while chatting with someone about optimising a little embedded webserver the other day and I spotted this.
http://www.monkey.org/~provos/libevent/
Whatever the policy tweaks, if any, maybe this offers some ideas regarding the implementation, not least of all because it unifies several kinds of IO at the same point, including stdio.
Andy
On Mon, 8 Aug 2011 10:57:15 -0700 Miller Puckette msp@ucsd.edu wrote:
On Mon, Aug 8, 2011 at 12:26 PM, Jeppi Jeppi jeppiot@hotmail.com wrote:
I can confirm this behaviour. I have run into a similar situation over a year ago when I was sending audio over udp (using udpsend~/receive~ from mrpeach collection). However, the GUI would stop updating at different time intervals. Having become aware of this problem in a very short time before an event, my workaround was another instance of Pd running a complementary GUI (communicating, again, over udp/OSC but with lower data rate, maybe). Frustrating, indeed. I spoke with Martin about this briefly and promised to test more and try to put my finger on the problem but I never really got around to it. Anyways, this may not help but at least I'm glad to know I was not crazy when I experienced that. I have seen this both on MacOSX and Linux, pdextended 42.5 (iirc).
./MiS
On Sun, 7 Aug 2011, Hans-Christoph Steiner wrote:
Do you realise that this escaping code relies on a massive change of the GUI code ? You wouldn't need the whole set of DD's GUI changes (no need to import DD's buggy parts, for example...) but it would be a quite massive change.
Otherwise, you'd have to rewrite the escaping code so that it fits in Pd 43.
Basically, IIRC, what happens is that DD saves spaces/backslashes/braces/etc correctly to disk when within symbols. All versions of PD are already equipped to load them correctly, but not to save them. Then DD's GUI code uploads single lines of .pd files to the GUI side and then the GUI side parses them correctly.
Note that apart from PD's C-based parser and DD's Tcl-based parser, all other parsers that people have posted on pd-list and/or puredata.info are incomplete parsers, as they can only parse what PD can currently save, not what it can currently load.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Aug 8, 2011, at 12:46 PM, Mathieu Bouchard wrote:
My guess is that it'll have to be a combo of moving Pd 0.43 to the DD
approach and rewriting the DD code to fit into 0.43. It sounds like
you have 'pd-gui' saving the file using Tcl code. It should be
possible to port that saving code to C and have it part of 'pd', and
that would then fit into the existing code much easier.
Would the easiest first step be writing a single, complete escape
mechanism for the pd <--> pd-gui communications?
.hc
“We must become the change we want to see. - Mahatma Gandhi
On Mon, 8 Aug 2011, Hans-Christoph Steiner wrote:
Well, no, or originally not. Ctrl+s is still done by server-side savefn. What you are replying to, was about how the server uses savefn to send stuff by sys_vgui. There are additional layers such as sys_mgui, pd_upload, gobj_subscribe, gobj_changed, manager_class, but basically, savefn sends by sys_vgui.
In desire.tk, I did add the ability to turn a client-side object into a pd source line (#X obj ...) but that was much later in the project, when I added the ability to copy client-side objects to the system clipboard (so that you can paste into a text editor...). This feature could also be used as an alternate way to save to disk, but it's currently not used like that. That feature was called "deconstruct" internally, because it produces the arguments that are needed to construct an object identical to the original, thus it's an opposite of the constructor in that way (but I could have named it savefn too).
Would the easiest first step be writing a single, complete escape mechanism for the pd <--> pd-gui communications?
The first step for achieving what ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Hi, just a simple question...how could I output textfiles from a pd patch (with any suitable object dealing with symbols) with \n in them? It seems I cannot type the "" character in pd...is that true?
Thanks in advance Josep M
On Tue, 9 Aug 2011, Jeppi Jeppi wrote:
just a simple question...how could I output textfiles from a pd patch (with any suitable object dealing with symbols) with \n in them?
You can use a sprintf that supports multiple arguments, such as [gf/sprintf] (from GridFlow).
Then putting a %c corresponding to a 10 will output a newline... if on Linux.
On Windows you need %c%c with 13 10.
It seems I cannot type the "" character in pd...is that true?
yes
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/09/2011 10:31 PM, Jeppi Jeppi wrote:
Hi, just a simple question...how could I output textfiles from a pd patch (with any suitable object dealing with symbols) with \n in them?
use the "cr" modifier to indicate that you want to save with CR line-endings rather than a terminating semicolon.
[write /tmp/foo.txt cr( | [textfile]
fm,gasdr IOhannes
On Aug 9, 2011, at 2:17 PM, Mathieu Bouchard wrote:
The first step to achieving fully escaped pd-gui communication and
file saving/loading so that all chars are valid. Are you interesting
in working on this? It would be a huge improvement, and I will
definitely help where I you want me to.
.hc
http://at.or.at/hans/