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