Well, anyway, I was hoping for a simpler answer, and my original guess was that the control rate limit might be at the block size, now I'm all confused :)
I'm seeing that maybe we can't really measure the speed efficiently in a patch, and that Pd might actually be able to manage tiny and fasty clocks, but that there is also a limit on the way they are computed that depends on the block size, right? What about a block size of one, and a large sample rate? I wonder if we could get control messages to work at 192Khz for example, huh? One way or another, I guess there might be a pretty straightforward answer to this. I didn't find any in Miller's book yet. cheers 2015-03-12 16:42 GMT-03:00 David Medine <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>: > >> >> >> 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>>: >>> >>> 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>>>: >>> >>> 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> >>> >>> >>> > > > _______________________________________________pd-l...@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 > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list