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 <[EMAIL PROTECTED]> 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 _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list