[PD] program for osc-rate testing?

[João Pais]

>> 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