...

I wanted to test the rate/stability of the osc packages I am sending
from Pd (around 3 packages every 40 ms) with another program outside Pd. Does anyone have any good sugestions for a programm (or even console utility) that can display the timings between the messages received on the port
I'm sending to? I'm using XP and ubuntu (I guess the later one is more suited for this).

I was also thinking of creating a "control tester" like a Pd patch that saves a click to an audio file every time a message is received. But
that would still be inside Pd, so I don't know how precise it would be.

Do you assume it to be less precise in Pd? You could have a separate instance of Pd for the testing suite, then it wouldn't be 'still inside Pd'. Also, recording a click on each received message to a sound file would definitely be possible, but wouldn't it be a bit cumbersome to read it out? Wouldn't it be more feasible to write timestamps taken with [timer] or [realtime] to a text file with [textfile]?

I already used 2 methods inside Pd to test the stability of the osc
instructions going out from the patch:

• by measuring the time with [realtime] into a textfile: it gave me values

between 25ms and 65ms, where they should always be at 40ms (there's a
[metro] sending the events)

• in a separate pd patch receiving the osc flux, making those instructons

record a [vline~] ramp in an audio file: All events are stable at 40ms,
except every ~1,5s (at unregular paces) there's one event that delays
itself by 10ms, catching up in the next event (like
...-40-40-30-50-40-40-...)

So, I already used Pd to try to measure this, and got 2 different results.
That's why I'm looking for a more "imparcial" measuring technique, located
on the receiver side (I guess 40ms isn't that heavy for a osc rate). Having a different Pd patch on the side (being the same instance or not),
is still "inside Pd". E.g. I don't know if the irregularities in the click
log I recorded come from the events themselves, or from [vline~] adjusting
to the audio blocks (a problem similar to the one I mentioned some weeks
ago in another thread). The help file says "The [realtime] object is as much like your own wrist
watch as Pd can possibly manage. It measures time according to your
operating system's internal clock." Looking at the results I had (and even
by using the 3 s count in the help patch) I don't know how much I can
trust [realtime].

João