> timer and realtime compute 2 different things 
> (logical time and real time). i don"t know what 
> your want.

I know they are different, and I don't really know what I want either :)

I just wanted to measure how long it takes between each control message.

you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working.

> what i don't understand is your intention with 
> the spigot in the patch.

just wanted to have a way to close the message stream, but you can forget about it

cheers

2015-03-12 14:14 GMT-03:00 Cyrille Henry <ch@chnry.net>:


Le 12/03/2015 18:04, Alexandre Torres Porres a écrit :
"/i don't understand your patch.

using [timer], a delay 0 will give a 0 delay...
logical time will always be consistent./"

well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this...
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.

what i don't understand is your intention with the spigot in the patch.

cheers
c


So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this.

thanks


2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>>:

    hello,

    i don't understand your patch.

    using [timer], a delay 0 will give a 0 delay...
    logical time will always be consistent.


    cheers
    c


    Le 12/03/2015 15:41, Alexandre Torres Porres a écrit :

        ok, so the metro at 1ms is because I'm using extended.

        as for the minimum time pd can process and send data, what's the final word on it?

        something like 1.4013e-45 ms?

        cause that's a lot more than an audio rate at 44.1khz :)

        I thought there was a limit control rate that was below the audio rate, but curiously it can go over.

        1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer]

        check my patch attached, based on the one that was sent here on the thread.

        thanks

        2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>:

             hello,

             Le 12/03/2015 10:12, Roman Haefeli a écrit :

                 On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote:

                     hello

                     this patch show the same behaviors for a delay based metro and a [metro].
                     (both can do faster than 1ms period)


                 You're right. More recent versions of Pd (>= 0.45?) have an updated
                 [metro] that supports many more ways to specify time and the restriction
                 was lowered. However, the [metro] in any available version of
                 Pd-extended is still limited to 1ms.

             sorry, i was not aware of this old limitation.


                 I don't understand why you use [realtime] and not [timer] to illustrate
                 your point. [timer] gives you consistent values (logical time) while
                 [realtime] is very jittery and shows just some random value depending on
                 the current cpu usage and probably other factors. When you render a
                 soundfile, the logical time is actually the one that matters.

             yes, for things that stay in pd, logical time is better.
             but if you want to send midi note, [realtime] is more related to what happens.
             it's just the way i understand the original question.

             cheers
             c



                 Roman



                 ___________________________________________________
        Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list
                 UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>>


             ___________________________________________________
        Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list
             UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>>




        _________________________________________________
        Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
        UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>


    _________________________________________________
    Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
    UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>