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