[PD] dumpOSC feature request

[Stephen Sinclair]

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...

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.

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.