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.)
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.
Here's a link to the app if anybody wants to take a quick glance at it for any glaring problems:
http://www.vato9.org/pd http://www.vato9.org/pd
...and download rsmidi.pd.
Thanks, rs
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
On Wed, 6 Oct 2004, IOhannes m zmoelnig wrote:
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.
Hi, the [expr] object does the parsing once, at object construction time, so I would like to know why you say that.
Besides, I also thought that [inlet]/[outlet] have some overhead because the message system is interpreted. Those objects also have a "dsp" handler defined so it appears as if it is not being optimised-out. Are you sure about this one?
I've had a quick look at pd/extra/expr~/ and pd/src/g_io.c; i don't know whether that's enough...
Matsjö Buschahr @ Medien.kunstLabor.AT, Graz, Österreich http://convention.puredata.info/ http://artengine.ca/matju
Matju wrote:
On Wed, 6 Oct 2004, IOhannes m zmoelnig wrote:
[expr] has to parse the expression, which is costy.
Hi, the [expr] object does the parsing once, at object construction time, so I would like to know why you say that.
right, probably you caught me talking nonsense. i have to admit that i never really looked at the expr-code, but my feeling told me, that it should not be faster than regular objects.
anyhow, i don't like the [expr] because *often* it makes things so less readable (in my opinion [expr $f * 3.14159 / 180] is less readable than the use of [* 3.14159] and [/ 180])
apol.
mfg.as.aer IOhannes
IOhannes m zmoelnig wrote:
anyhow, i don't like the [expr] because *often* it makes things so less readable (in my opinion [expr $f * 3.14159 / 180] is less readable than the use of [* 3.14159] and [/ 180])
Of course here for speed one ought to use [* 0.017453278], but the reason for the number is less obvious so a comment like 'pi over 180' is in order, which adds nothing to the processing time.
Martin
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.
i made a small benchmark a short time ago ... it turned out that |expr| and pd objects are about the same speed ...
if speed really matters, the best thing would be to use k_cext ...
cheers ... tim
-
IOhannes m zmoelnig -
Martin Peach -
Matju -
Ryan Supak -
Tim Blechmann