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