hi,

im a newbie to PD, but not to programming (C++) and Im pretty competent with Max/MSP.

I decided to give PD a try, as I want to use it on a Raspberry PI and Linux environment.

anyway, my issue is:
Ive written a program (in C) that sends alot of messages via OSC to be picked up by OSC, using mrpreach udpreceive/unpackOSC/routeOSC etc.
and Im testing it on my Mac, and PD is seriously lagging behind processing the osc messages. yet the CPU load is pretty load.
... to me it appears that perhaps a control rate needs to increased?
(assuming PD is like Max and Reaktor which has two rates for message processing)

I need to process about 1000 osc message/sec, perhaps more ... though I think its lagging behind at substantial less than that.

exactly the same setup works absolutely fine on Max/MSP (7.2) , so I think its something to do with my PD setup.
but I tried both pd-extended and pd-vanilla (as it mores up to date) and both had the same issue.

• is there some concept of 'control rate' in PD? can I increase this some how?
• is this likely to be a Mac only issue, or on all versions of PD? (e.g Linux)
• are these the best processing objects for OSC?

thanks for any help
Mark

p.s. any recommendations on best PD setup for the Mac? pd-extended seems very old, it seems perhaps pd-vanila + the defin (?) extension finder is best option.

setup:
PD 0.46-6-64 bit (vanilla) + mrpeach extensions
Mac OSX 10.11.2
(also tried latest PD-extended, 32 bit, same issue)

Perhaps you should try with the vanilla object netreceive and you should avoid to print the received messages in the console.

@thetechnobear I have always used [dumpOSC] in extended....... with up to 64 users sending many messages / sec......... but I have never counted how many actually arrive (maybe 64x100 on average?). I agree that you should not print to terminal, and you should keep displayed gui's to an absolute minimum. In Pd everything that can be done (quite a lot on a modern PC) is done as fast as possible between audio ticks, which makes me think always that any "struggling" in processing is because Pd is not communicating efficiently with the soundcard(s)....... and those settings should be checked.
Maybe you could post your testing program...... and we could test it on different platforms (including the Pi)......
David.

I dont print to the output, I route it to drive an oscillator (and for debugging purposes to num boxes)

Ive got an external audio interface, a saffire pro 14, and that seems to be working fine, and as mentioned, there is no evidence of cpu load... and the audio is glitch free... its just the messages not being processed quickly

as you can see the basic function (for testing) is to drive an oscillators frequency, and mix in another parameter to get the volume (gain)

a few notes:

• Ive tested without the num boxes etc, i.e. just the oscillator and the issue is the same.
• its the same with only one half i.e. one udpreceive 'tree' and its the same

unfortunately, you can't test as such without the relevant controller and application to send the messages.

I'll try netreceive... perhaps that will help.
EDIT: nope, netreceive has exactly the same issue.
EDIT: oops, noticed the 9002 tree, i went via the num boxes to oscillator/gain, but taking directly from the unpack, still has no change

mectest.pd

You said you tried the vanilla OSC native objects ([oscformat]/[oscparse])? These should be combined with [netreceive -u -b] (-u is for UDP and -b for binary).
You said you have vanilla-64bit. That might be an issue when working with external objects (like [udpreceice], [unpackOSC] etc.). Not sure if that could be the case, but the native objects are more likely to play nice since the 64bit version is a quite special one and most of the externals are 32bit.

I just tried with this patch

test_oxc_cpu.pd
On my Mac 10.11.3 , 2.3Ghz and PD-vanilla -32bit:
1000 messages -> ~1% CPU
10000 messages -> ~10% CPU
50000 messages -> ~50% CPU

And do you really need 1000 messages ? For exemple, if you want to set the frequency of [osc~], the object will take into account only the last value before the next DSP tick. So at 44100Hz it can take into account 44100/64≈690 changes but is it really necessary to change the frequency at each DSP tick ?

ok, so now I've tried netrecieve with oscparse , so I'm up to this now... and same issue...

Ive been trying to get to grips with pure datas processing model,
so Ive read control rate is 1 dsp buffer

so I've got in my audio settings a block size of 64, which i assume is 64 samples.
at 48000 that means I should be getting 750hz (or 750 msg/sec ) , which should be enough, given thats what I have max set at.

I note, I cannot seem to change the block size as this seems to crash Pd ... I was hoping to try say 16.

(also I don't get what 'delay(msec)' is ... the web page is a bit vague.

@Pierre-Guillot yeah I think your right, I can throttle the data back to a rate that works...

Ive just done some more tests, and I suspect I was 'just over' 750 msg/sec , which is why a few seconds of activity would result in a fractional delay.
once I throttle back to around 500 msg/sec the issue seems to go away.

its got me wondering what Max is doing in this case (it set up the same and copes fine) , Im wondering if its doing something like rate limiting the messages, where as Pd, is just queuing them all up.

thanks to all for your help, not only have I learnt a some thing about Pd message processing, but I can now I can use vanilla pd objects, without extras

cheers

@thetechnobear It is definately a "per port" or a "per thread" issue in Pure Data.....
These tests are built in extended........ turn down the volume before you start them........
message tests.zip
nearly 700 osc message strings per second can be achieved "on time" per port with a maximum of 63 ports. The 64th port kills the patch (I have stumbled upon this limit before)............
So if you can spread your messages across ports then (about) 42600 messages per second can be processed on time...........
Beyond the "700ish" limit per port/thread there are delays, but every value is still printed..........
David.