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