Pd stops parsing OSC when DSP is activated

Reply to Pd stops parsing OSC when DSP is activated on Wed, 25 Mar 2015 06:50:56 GMT

Epic Jefferson — Wed, 25 Mar 2015 06:50:56 GMT

I'm sending leapmotion data from openframeworks to pd vanilla 0.46-5. OSC stops parsing the moment I activate DSP in Pd. The only data I get is about 4 seconds AFTER I remove my hand from the leap's view, and it's a dump of OSC data. When DSP is off, I get the expected stream of OSC data.

In case it was something to do with audio, I tried using jack but it doesn't change anything. Has anyone encountered this before?

pd-extended 0.43.4 also has the same problem, although it's all the time, not only when audio is activated. For pd-extended I'm using [dumpOSC] and for vanilla I'm using the new [netreceive -u -b]

I'm on osx 10.10

Reply to Pd stops parsing OSC when DSP is activated on Wed, 25 Mar 2015 14:09:56 GMT

whale-av — Wed, 25 Mar 2015 14:09:56 GMT

Hello,
Which os?
I have comms problems as well at the moment, but not the same as yours.
However, our paths might cross somewhere.... so here goes.
I am using (normally with great pleasure) pd extended on win7.
Usually I would start from pd.exe, or call it in a batch file, and all was well.
Then, because (obviously) of something that I had done, dumpOSC stopped working completely.
I reinstalled pd, reset params, even considered tinkering with pd's own load switches, but to no avail.
The same patch works fine calling pd.exe on all of my other computers.
So I tried starting it from a batch file calling pd.com, and I was back to normal working (whew!).
pd.exe still dead for dumpOSC though.
So I moved on, and started stress testing my patch.... 100 audio input channels 100 out, 4 band parametric on all ins and outs.... etc.
udpsend gives up the ghost at 64 instances, and will not resume normal working without a reboot (re-starting pd is not sufficient. I put this one down to the os maybe.... about to start my research!
David.
David.

Reply to Pd stops parsing OSC when DSP is activated on Wed, 25 Mar 2015 19:08:15 GMT

portabello — Wed, 25 Mar 2015 19:08:15 GMT

I had this exact same problem when sending large amounts of OSC data from oF to PD. I ended up creating another oF program that receives the OSC data, converts it to PD's FUDI message format, and then sends the converted message along to PD. This helped reduce the delay a bit. I also modified my oF program to only send the continuously updating OSC data every X frames. This isn't an ideal solution but it worked well enough for my project.

Another possible solution would be to use the ofxPd addon and redo everything using libPd.