[PD] dumpOSC feature request

[Hans-Christoph Steiner]

On Jun 19, 2007, at 3:53 PM, Stephen Sinclair wrote:

> I just wanted to say, I definitely agree to this request.
> I think the dashed-outline should _exclusively_ reserved for objects
> that fail to load.
> They should not fail to create if they are loaded.
> If they have bad arguments, they should be created, but simply refuse
> to work properly.
> It would be far less confusing, otherwise you are stuck there
> wondering why Pd can't find the object when it is on the path...

I totally agree, this is a good outline of how it should work for all  
objects.  If it loads and then doesn't do anything, at least you can  
open the help patch.

> That said, I posted a patch against dumpOSC to have it create properly
> if another instance is already listening on the same port... but only
> for multi-cast ports, since logically it should work like that.  I'd
> be happy to make further modifications to get dumpOSC working as
> requested here.
>
> I finally have a bit of time (just submitted my thesis yesterday!) so
> I might attack a few more OSC bugs.

Before putting too much effort into the messy dumpOSC/sendOSC, you  
should check out Martin Peach's OSC and network objects.

.hc

>
> Steve
>
>
> On 6/18/07, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
>> Richard Lewis wrote:
>>> Hello PD list,
>>>
>>> Further to that response I gave about problems with OSC.
>>>
>>> I'd like to make a feature request/bug report: when you try to  
>>> create a
>>> dumpOSC object using a port which is already in use, PD acts as  
>>> if the object
>>> cannot be created - it renders the box with a dashed outline and  
>>> reports the
>>> error "...couldn't create". This is actually very confusing as  
>>> the user then
>>> assumes that PD can't find the object code and tries to solve the  
>>> problem by
>>> checking library paths etc.
>>>
>>> A better way of handling this error would be if the dumpOSC  
>>> object, upon
>>> finding that it can't attach to a port, sends an error message to  
>>> that effect
>>> to the PD console.
>>>
>>> Any thoughts?
>>
>> no thoughts, just remarks:
>> [dumpOSC] behaves the same as [netreceive], so the behaviour is
>> consistant (though annoying) with pd's default behaviour for many  
>> a year.
>> then, doesn't [dumpOSC] write something to the PD console before it
>> fails to create? (like: port already in use).
>>
>> then, i found [dumpOSC] to be buggy anyhow, and suggest using  
>> mrpeach's
>> osc/net externals for the same purpose (you can easily create  
>> [dumpOSC]
>> as an abstraction that is 100% compatible, but has less errors and  
>> the
>> underlying code is still maintained).
>>
>> finally, it would be good to have a way to get notified (on a patch
>> level, not just the console output) of objects that failed to create.
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



------------------------------------------------------------------------ 
----

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.    -William Carlos Williams