|Forwinder||Aug 22, 2008 8:11 am|
|Frank Barknecht||Aug 22, 2008 9:30 am|
|IOhannes m zmoelnig||Aug 23, 2008 3:07 am|
|Luke Iannini||Aug 23, 2008 4:15 am|
|IOhannes m zmoelnig||Aug 23, 2008 5:02 am|
|Claude Heiland-Allen||Aug 23, 2008 5:14 am|
|Frank Barknecht||Aug 23, 2008 5:18 am|
|Claude Heiland-Allen||Aug 23, 2008 5:25 am||.c|
|Martin Peach||Aug 23, 2008 7:55 am|
|Frank Barknecht||Aug 23, 2008 8:00 am|
|Stephen Sinclair||Aug 23, 2008 9:33 am|
|forwind||Aug 25, 2008 10:33 am|
|Hans-Christoph Steiner||Aug 26, 2008 4:58 pm|
|Subject:||[PD-dev] dump OSC bugs?|
|Date:||Aug 22, 2008 8:11:57 am|
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,