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?
Cheers, Richard
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.
mfga. IOhannes
Cheers, Richard
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.
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
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
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.
Exactly.
Before putting too much effort into the messy dumpOSC/sendOSC, you should check out Martin Peach's OSC and network objects.
I haven't really used them yet, but since they are more actively developed, I suppose a decision should be made at some point about whether to leave dumpOSC/sendOSC in Pd?
Since the mrpeach objects don't include both network and OSC stuff in the same object, perhaps replacement objects could be created using his routines, a simple mash-up of the peach udpsend/receive and his packOSC routines. Perhaps it could even be done as an abstraction.
Would there be any point doing that?
Mainly I just think it would be simpler if we standardized on a single OSC implementation.. But then again it would be some work just to replace objects that we already have.
Steve
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Richard Lewis -
Stephen Sinclair