On Jul 8, 2010, at 8:57 AM, Martin Peach wrote:
IOhannes m zmoelnig wrote:
On 2010-07-07 04:03, Hans-Christoph Steiner wrote:
Hey Martin,
I've been using udpsend/udpreceive in a project and they've been great. I have one small request, which I'd happily implement if you don't want to. For the error like "not connected", it would be very handy if they used pd_error() so that the error is findable.
i started doing this a while ago, and eventually stopped[1] it again. the reasoning behind this is: as you have well observed, pd_error() allows you to find the error with the find menu. the target case for this is patching errors (e.g. sending a symbol to a float-only inlet) where you want to find the erroneous code and fix it. an error like "not connected" is very much unlikely to be caused due to a patching error. it's more likely to be caused of user-error, e.g. because the given remote host is unavailable. "users" (as opposed to patchers) have a different role and are potentially different people. i believe that they should have a different feedback. (even if patcher and user are the same person, they will gain more insight if they know right from the start whether the problem is a syntax error or a logical error) [2] it should be possible to get feedback within the patch for all errors caused by user-input. so if you get "not connected", there should be a way for the patch to know about this. if this is the case, you can manually "throw" a findeable error by means of things like [canvaserror] anyhow.
I agree that the console should not be used for messages that can be handled in the patchwork. Once a message has left the patch only the user can handle it. [udpsend] currently outputs one or zero when its connection state changes. For in-patch control it might be better if it outputs a message like "connect 0" on disconnect and "connect 1" on connect. Then the same outlet can be used for other status messages and they can be routed within the patch. Attempting to send through an unconnected [udpsend] would then just cause it to emit "connect 0" from its outlet.
Martin
I agree with IOhannes' idea, but the reason why I wanted to add pd_error() was in direct response to patching errors. If a patch is going to be self-starting, then you can't rely on a person to click the [connect( message, for example.
I like Martin's idea of having it also output status info. I could see these net objects having a second status outlet for outputting the specific error info, connection status, etc. Then it would make sense to not use pd_error() and let the user program the logic for reconnecting, etc.
Perhaps for really simple networking, there could be a version that does use pd_error() and is more oriented towards clicking messages. It could use broadcast or multicast so that they don't even need to deal with IP addresses.
.hc
----------------------------------------------------------------------------
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne