Yeah, I am realizing now, as I continue to think about this instead of working, that I don't fully understand this detail.

On 3/12/2015 12:57 PM, Alexandre Torres Porres wrote:
"1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do."

I got less in a mac with pd vanilla 0.46-5 64 bits, tried 1e-08 on [delay] and it was not accurate, [timer] giving me around 9.73e-09

then tried even lesser numbers and [timer] stopped 1.08126e-09

2015-03-12 16:42 GMT-03:00 David Medine <dmed...@ucsd.edu <mailto:dmed...@ucsd.edu>>:


    My understanding of this patch and the guts of Pd tells me that
    this patch isn't really going to measure how long it takes between
    each control message. What it can do is show the time resolution
    of calls to sys_getrealtime, which is Pd's method of querying the
    CPU clock:

    double sys_getrealtime(void)
    {
    #ifndef _WIN32
        static struct timeval then;
        struct timeval now;
        gettimeofday(&now, 0);
        if (then.tv_sec == 0 && then.tv_usec == 0) then = now;
        return ((now.tv_sec - then.tv_sec) +
            (1./1000000.) * (now.tv_usec - then.tv_usec));
    #else
        LARGE_INTEGER now;
        QueryPerformanceCounter(&now);
        if (nt_freq == 0) sys_initntclock();
        return (((double)(now.QuadPart - nt_inittime.QuadPart)) /
    nt_freq);
    #endif
    }

    The code is from s_inter.c. It is apparent (at least in the
    non-Windows part of the code) that there is a microsecond
    resolution, hence 1e-6, but I could misunderstanding this. I was
    able to put 1e-7 on a Windows machine and it still worked -- I
    haven't had a chance to do try it in Unix/BSD land and I don't
    actually want to know what Windows is doing with this QuadPart of
    a LARGE_INTEGER. Still, (on Linux and Mac, anyway) 1us is the
    smallest unit of time that Pd's clocks keep track of, so that
    should be the limit of what [delay] can do.

    The actual time it takes for Pd to deal with messages depends on a
    great many things. Symbols in Pd are stored in a hash table, so I
    would guess that the size of the table (which needs to be
    searched) is the main factor controlling the rate at which those
    messages can be handled. However, I suspect that the number of
    symbols needed to slow Pd down on a modern computer is
    impractically large. Then there are control messages that don't
    have hashed symbols associated with them (like floats and bangs).
    Also, some external controls -- especially mouse/keyboard events
    and MIDI -- can be badly timed. These tend to queue up and get
    spit out at the OS's whim. Pd then simply does what it can with
    what it gets. So measuring the exact time it takes to /do/ control
    in Pd is pretty hairy. I don't believe that meaningful
    measurements of this can be done with a Pd patch.

    The other thing is that control messages get rolled up between dsp
    ticks and are then applied immediately on the start of the next
    tick. This means that two messages that are, say, .05ms apart
    somewhere in the midst of a 1.45ms block, get applied
    simultaneously at the start of the next block. This also means
    that at 44.1kHz with a block size of 64 samples, both of them may
    be anywhere from 0.02 ms to 1.45ms late -- depending on where they
    fall in relation to block boundaries. This also, also means that
    if one control message happens near the end of one block and the
    other happens near the start of the next block, their distance of
    .05ms in physical time will be expanded to 1.45ms. This is a very
    big, teeny-tiny problem in real-time audio programming because
    under certain conditions there can be serious (audible)
    repercussions. This is why there is [vline~], by the way.

    If anyone else is interested in this stuff, I recommend these
    lectures (Miller's is the first in the series):
    http://repmus.ircam.fr/mutant/rtmseminars

    -David


    On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:
    > 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 <c...@chnry.net
    <mailto:c...@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 <c...@chnry.net
            <mailto:c...@chnry.net> <mailto:c...@chnry.net
            <mailto:c...@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
            <c...@chnry.net <mailto:c...@chnry.net> <mailto:c...@chnry.net
            <mailto:c...@chnry.net>> <mailto:c...@chnry.net
            <mailto:c...@chnry.net> <mailto:c...@chnry.net
            <mailto:c...@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>>
            <mailto: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>>
            <mailto: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>


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





    _______________________________________________
    Pd-list@lists.iem.at  <mailto:Pd-list@lists.iem.at>  mailing list
    UNSUBSCRIBE and account-management 
->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



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

Reply via email to