[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