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)

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

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 ?

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.

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