[PD-dev] pd_error() for udpsend, tcpsend, etc.

[Hans-Christoph Steiner]

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