[PD] Ways to decrease processing delay?
IOhannes m zmoelnig
zmoelnig at iem.at
Wed Oct 6 17:37:59 CEST 2004
Ryan Supak wrote:
> Hi,
>
> I'm a beginner using PD as a realtime MIDI processor, and with the help of this list, I've been able to prototype my application in just 2 short evenings.
>
> Now, I'm looking to make my app as tight and fast as possible.
>
> I've used the minimum amount of code whenever possible -- it's probably not as elegant as it could be, but there are no apparently obvious gas-guzzling portions of code. (It does use 2 subpatches, I don't know if those are slower or not.)
the subpatches will add *no* delay at all.
the number of objects will affect the delay *not* at all.
whenever a message is triggered, all resulting message operations are
executed _immediately_ (in logical time).
of course, real time is not the same as logical time.
normally processors are so fast, that this difference does not matter.
>
> Also, since the app does not require audio processing, I used the -noaudio flag. I tried using the -nogui flag but it doesn't seem to work at all then.
>
you problem is most likely, that the triggering of messages is quantized
quite heavy. (normally in blocks of 64 samples which is about 1.5ms)
if you are running with "-noaudio" this might be worse!!
however, you can set the granularity with the "-sleepgrain" option, to
get faster responses.
ah, one last word:
when trying to reduce the amount of calcs that need to be done, consider
not using [expr].
[expr] has to parse the expression, which is costy.
[moses] should be perfect for your needs.
mfg.a.sdr
IOhannes
More information about the Pd-list
mailing list