Hi all,
I noticed some very strange behaviour while using dumpOSC last night. I have a python script which communicates with my pd patch through OSC. The idea being it sends OSC messages on two separates ports to emulate a stereo control pair of channels. I have tested the python code with two separate OSC clients listening to the messages and all seems very hunky dorey with excellent high through put etc. One client being a separate python process listening to the appropriate port number and the other being the command line dumpOSC utulity which comes with the dumpOSC external.
But when I introduce PD into the equation with the dumpOSC external, the message drop out is significant. By message drop out I mean pd's dumpOSC externals ( as I use two dumpOSCS to read from both port numbers) tend to read from one port or the other with values from one port being read properly and 0 being read from the other port. When I compare this in real time with the trace from another client listening to the same output there are no 0's, i.e. no drop out !
The funny thing as I explained above is that one of the other clients I used to debug this was the command line dumpOSC command line tool. this showed no drop out/0's. Without looking under the bonnet and with one wet finger high in the sky (i.e. I'm guessing) this all scarely points to a flaw in the PD architecture to able handle multiple OSC control streams properly. Is this the case or should I use a different external or god forbid am I being silly ?
Am I testing this on a 64bit architecture running at a ridiculous speed which I have a gut feeling is the cause for exposing this 'bug'. I seem to remember this working fine on a 32 bit os. I'm running PD 0.39 straight from the apt-get repository. I should really compile the stable trunk from svn.... lazy lazy me.
Good weekend all,
Conor
Hallo, Forwinder hat gesagt: // Forwinder wrote:
The funny thing as I explained above is that one of the other clients I used to debug this was the command line dumpOSC command line tool. this showed no drop out/0's. Without looking under the bonnet and with one wet finger high in the sky (i.e. I'm guessing) this all scarely points to a flaw in the PD architecture to able handle multiple OSC control streams properly. Is this the case or should I use a different external or god forbid am I being silly ?
You could use the osc externals by Martin Peach (in the "mrpeach" directory of the Subversion repository) as a comparison. Or even netreceive from standard Pd, but that only speaks the "FUDI" protocol, not OSC, so would require a rewrite of the Python script but at least FUDI is even simpler than OSC.
Ciao
Forwinder wrote:
Hi all,
I noticed some very strange behaviour while using dumpOSC last night. I
the OSCx-library (that includes the [dumpOSC] object) is known to be broken and unmaintained.
it is only there for legacy reasons. please do not use it.
if you want to use OSC, use mrpeache's objects.
fmgadr. IOhannes
On Sat, Aug 23, 2008 at 3:07 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Forwinder wrote:
Hi all,
I noticed some very strange behaviour while using dumpOSC last night. I
the OSCx-library (that includes the [dumpOSC] object) is known to be broken and unmaintained.
it is only there for legacy reasons. please do not use it.
if you want to use OSC, use mrpeache's objects.
Yo, What about adding a "DO-NOT-USE---LEGACY-ONLY---USE-MRPEACH-help.pd" patch to the oscx directory : ) (and similar warnings inside the OSCx object help files) Best Luke
fmgadr. IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Luke Iannini wrote:
On Sat, Aug 23, 2008 at 3:07 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Forwinder wrote:
Hi all,
I noticed some very strange behaviour while using dumpOSC last night. I
the OSCx-library (that includes the [dumpOSC] object) is known to be broken and unmaintained.
it is only there for legacy reasons. please do not use it.
if you want to use OSC, use mrpeache's objects.
Yo, What about adding a "DO-NOT-USE---LEGACY-ONLY---USE-MRPEACH-help.pd" patch to the oscx directory : ) (and similar warnings inside the OSCx object help files)
whenever i find the time, i want to add a note into the constructor of the OSCx objects, so you get a warning each and everytime you create one of these objects. if someone finds the time before me, i would be glad...
fmgadsr IOhannes
IOhannes m zmoelnig wrote:
whenever i find the time, i want to add a note into the constructor of the OSCx objects, so you get a warning each and everytime you create one of these objects. if someone finds the time before me, i would be glad...
can you make it use pd_error (or whatever it's called) so you can find the object more easily? would that even work in the constructor?
Claude
Claude Heiland-Allen wrote:
can you make it use pd_error (or whatever it's called) so you can find the object more easily? would that even work in the constructor?
I was curious, so I tested it..
Calling pd_error on the newly constructed object in the newmethod does work (in that find last error finds it), which is nice.
Claude
#N canvas 0 0 450 300 10; #X obj 87 131 errorconstructor;
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
whenever i find the time, i want to add a note into the constructor of the OSCx objects, so you get a warning each and everytime you create one of these objects.
I think, such warnings may be a bit too patronizing. Also OSCroute doesn't have any critical bugs AFAIK.
Bundling some replacement abstractions build with Martin's osc objects for ease of transition would be useful, though, and the osc help files could benefit from some polishing like replacing [prepend] with a no-nameclash solution based on [list] etc.
Ciao
Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
whenever i find the time, i want to add a note into the constructor of the OSCx objects, so you get a warning each and everytime you create one of these objects.
I think, such warnings may be a bit too patronizing. Also OSCroute doesn't have any critical bugs AFAIK.
Bundling some replacement abstractions build with Martin's osc objects for ease of transition would be useful, though, and the osc help files could benefit from some polishing like replacing [prepend] with a no-nameclash solution based on [list] etc.
Probably moving the mrpeach osc objects (routeOSC, packOSC and unpackOSC) into an /osc folder and the net objects (udpreceive, udpsend, tcpreceive, tcpsend, tcpclient, tcpserver) into a /net folder would be a good idea, making them easier to find for the uninitiated. Unfortunately it would break some existing patches that currently use the /mrpeach prefix. And I'm not sure how much svn enjoys moving things around like that.
Martin
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Probably moving the mrpeach osc objects (routeOSC, packOSC and unpackOSC) into an /osc folder and the net objects (udpreceive, udpsend, tcpreceive, tcpsend, tcpclient, tcpserver) into a /net folder would be a good idea, making them easier to find for the uninitiated.
I think, that's a great idea.
Unfortunately it would break some existing patches that currently use the /mrpeach prefix.
They could make a copy or symlink, if the OS allows, to the old location.
And I'm not sure how much svn enjoys moving things around like that.
Moving is well supported in SVN, much better than in CVS. I cannot comment if it breaks something in pd-extended or how its (auto)build system has ot be adapted.
Ciao
On Aug 23, 2008, at 10:55 AM, Martin Peach wrote:
Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
whenever i find the time, i want to add a note into the constructor of the OSCx objects, so you get a warning each and everytime you create one of these objects.
I think, such warnings may be a bit too patronizing. Also OSCroute doesn't have any critical bugs AFAIK.
Bundling some replacement abstractions build with Martin's osc objects for ease of transition would be useful, though, and the osc help files could benefit from some polishing like replacing [prepend] with a no-nameclash solution based on [list] etc.
Probably moving the mrpeach osc objects (routeOSC, packOSC and unpackOSC) into an /osc folder and the net objects (udpreceive, udpsend, tcpreceive, tcpsend, tcpclient, tcpserver) into a /net folder would be a good idea, making them easier to find for the uninitiated. Unfortunately it would break some existing patches that currently use the /mrpeach prefix. And I'm not sure how much svn enjoys moving things around like that.
Just leave the objects in 'mrpeach' and old patches won't break. Then the 'mrpeach' lib could be deprecated in stages.
I think having clean, well organized 'net' and 'osc' libraries would be great. Before just moving them to 'net' and 'osc', I think there should be a clear idea of what a full-fledged 'net' and osc' libraries would look like. Each library should have standard interfaces and messages for the objects in that library.
'osc' would probably be an easier place to start, since it will most likely be smaller.
.hc
Martin
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
On Sat, Aug 23, 2008 at 8:19 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
whenever i find the time, i want to add a note into the constructor of the OSCx objects, so you get a warning each and everytime you create one of these objects.
I think, such warnings may be a bit too patronizing. Also OSCroute doesn't have any critical bugs AFAIK.
Bundling some replacement abstractions build with Martin's osc objects for ease of transition would be useful, though, and the osc help files could benefit from some polishing like replacing [prepend] with a no-nameclash solution based on [list] etc.
I think providing abstraction replacements is the best idea, imho. For one, it could be functionally identical, ensuring current patches don't break, and secondly I think it's actually useful and convenient to bundle the networking and OSC stuff into one object.
Steve
-
Claude Heiland-Allen -
Forwinder -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Luke Iannini -
Martin Peach -
Stephen Sinclair