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.
.hc
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
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.
Yes sure, go ahead and do it. I think all the error messages need to be looked at re that issue, when I have time... Also it would be nice to have some kind of guidelines for which error message to use when. There seem to be several variants available.
Martin
On Jul 7, 2010, at 9:15 AM, Martin Peach wrote:
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.
Yes sure, go ahead and do it. I think all the error messages need to be looked at re that issue, when I have time... Also it would be nice to have some kind of guidelines for which error message to use when. There seem to be several variants available.
I see it like this:
post() - info error() - info labeled as an error pd_error() - findable error with info
IOhannes has been working on a more full fledged debug posting API around the verbose() function.
.hc
----------------------------------------------------------------------------
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.
fga,sdr IOhannes
[1] this is not entirely true. e.g. in Gem virtually all Object-emitted errors are posted using pd_error().
[2] thinking of this, i notice that in Gem there is only a single error() handle for both syntax-errors and runtime errros. i guess i should differentiate between these two kinds of errros (and probably still use pd_error() as a backend for emitting the messages in both cases)
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
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
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach