<div dir="ltr">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 :)<div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-12 16:42 GMT-03:00 David Medine <span dir="ltr"><<a href="mailto:dmedine@ucsd.edu" target="_blank">dmedine@ucsd.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
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:<br>
<br>
<font face="Courier New">double sys_getrealtime(void) <br>
{<br>
#ifndef _WIN32<br>
static struct timeval then;<br>
struct timeval now;<br>
gettimeofday(&now, 0);<br>
if (then.tv_sec == 0 && then.tv_usec == 0) then = now;<br>
return ((now.tv_sec - then.tv_sec) +<br>
(1./1000000.) * (now.tv_usec - then.tv_usec));<br>
#else<br>
LARGE_INTEGER now;<br>
QueryPerformanceCounter(&now);<br>
if (nt_freq == 0) sys_initntclock();<br>
return (((double)(now.QuadPart - nt_inittime.QuadPart)) /
nt_freq);<br>
#endif<br>
}</font><br>
<br>
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. <br>
<br>
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 <i>do</i> control in Pd is pretty hairy. I don't
believe that meaningful measurements of this can be done with a Pd
patch. <br>
<br>
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 <span> 0.02</span> 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.<br>
<br>
If anyone else is interested in this stuff, I recommend these
lectures (Miller's is the first in the series):<br>
<a href="http://repmus.ircam.fr/mutant/rtmseminars" target="_blank">http://repmus.ircam.fr/mutant/rtmseminars</a><br>
<br>
-David<div><div class="h5"><br>
<br>
<div>On 3/12/2015 10:25 AM, Alexandre Torres
Porres wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">
<div>> timer and realtime compute 2 different things </div>
<div>> (logical time and real time). i don"t know what </div>
<div>> your want.</div>
<div><br>
</div>
<div>I know they are different, and I don't really know what I
want either :)</div>
<div><br>
</div>
<div>I just wanted to measure how long it takes between each
control message.</div>
<div><br>
</div>
<div>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.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">> what i don't understand is your
intention with </div>
<div class="gmail_extra">> the spigot in the patch.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">just wanted to have a way to close the
message stream, but you can forget about it</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">cheers</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-03-12 14:14 GMT-03:00 Cyrille
Henry <span dir="ltr"><<a href="mailto:ch@chnry.net" target="_blank">ch@chnry.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
Le 12/03/2015 18:04, Alexandre Torres Porres a écrit :<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
"/i don't understand your patch.<span><br>
<br>
using [timer], a delay 0 will give a 0 delay...<br>
</span>
logical time will always be consistent./"<span><br>
<br>
well, I thought you were disucussing here and reaching
the conclusion that [timer] is the one to be used to
calculate this...<br>
</span></blockquote>
timer and realtime compute 2 different things (logical
time and real time). i don"t know what your want.<br>
<br>
what i don't understand is your intention with the spigot
in the patch.<br>
<br>
cheers<br>
c<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
<br>
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.<br>
<br>
thanks<br>
<br>
<br>
</span>
2015-03-12 11:55 GMT-03:00 Cyrille Henry <<a href="mailto:ch@chnry.net" target="_blank">ch@chnry.net</a> <mailto:<a href="mailto:ch@chnry.net" target="_blank">ch@chnry.net</a>>>:<span><br>
<br>
hello,<br>
<br>
i don't understand your patch.<br>
<br>
using [timer], a delay 0 will give a 0 delay...<br>
logical time will always be consistent.<br>
<br>
<br>
cheers<br>
c<br>
<br>
<br>
Le 12/03/2015 15:41, Alexandre Torres Porres a
écrit :<br>
<br>
ok, so the metro at 1ms is because I'm using
extended.<br>
<br>
as for the minimum time pd can process and
send data, what's the final word on it?<br>
<br>
something like 1.4013e-45 ms?<br>
<br>
cause that's a lot more than an audio rate at
44.1khz :)<br>
<br>
I thought there was a limit control rate that
was below the audio rate, but curiously it can go
over.<br>
<br>
1 sample at 44.1khz gives us 0.0226757 ms, and
I was able to send bangs at 1e-06 ms, according to
[timer]<br>
<br>
check my patch attached, based on the one that
was sent here on the thread.<br>
<br>
thanks<br>
<br>
</span>
2015-03-12 10:04 GMT-03:00 Cyrille Henry <<a href="mailto:ch@chnry.net" target="_blank">ch@chnry.net</a> <mailto:<a href="mailto:ch@chnry.net" target="_blank">ch@chnry.net</a>> <mailto:<a href="mailto:ch@chnry.net" target="_blank">ch@chnry.net</a> <mailto:<a href="mailto:ch@chnry.net" target="_blank">ch@chnry.net</a>>>>:<span><br>
<br>
hello,<br>
<br>
Le 12/03/2015 10:12, Roman Haefeli a
écrit :<br>
<br>
On Thu, 2015-03-12 at 09:17 +0100,
Cyrille Henry wrote:<br>
<br>
hello<br>
<br>
this patch show the same
behaviors for a delay based metro and a [metro].<br>
(both can do faster than 1ms
period)<br>
<br>
<br>
You're right. More recent versions of
Pd (>= 0.45?) have an updated<br>
[metro] that supports many more ways
to specify time and the restriction<br>
was lowered. However, the [metro] in
any available version of<br>
Pd-extended is still limited to 1ms.<br>
<br>
sorry, i was not aware of this old
limitation.<br>
<br>
<br>
I don't understand why you use
[realtime] and not [timer] to illustrate<br>
your point. [timer] gives you
consistent values (logical time) while<br>
[realtime] is very jittery and shows
just some random value depending on<br>
the current cpu usage and probably
other factors. When you render a<br>
soundfile, the logical time is
actually the one that matters.<br>
<br>
yes, for things that stay in pd, logical
time is better.<br>
but if you want to send midi note,
[realtime] is more related to what happens.<br>
it's just the way i understand the
original question.<br>
<br>
cheers<br>
c<br>
<br>
<br>
<br>
Roman<br>
<br>
<br>
<br>
</span>
___________________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>
<mailto:<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>>
<mailto:<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>
<mailto:<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>>>
mailing list<br>
UNSUBSCRIBE and account-management
-> <a href="http://lists.puredata.info/____listinfo/pd-list" target="_blank">http://lists.puredata.info/____listinfo/pd-list</a>
<<a href="http://lists.puredata.info/__listinfo/pd-list" target="_blank">http://lists.puredata.info/__listinfo/pd-list</a>>
<<a href="http://lists.puredata.info/__listinfo/pd-list" target="_blank">http://lists.puredata.info/__listinfo/pd-list</a>
<<a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a>>><br>
<br>
<br>
___________________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>
<mailto:<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>>
<mailto:<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>
<mailto:<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>>>
mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/____listinfo/pd-list" target="_blank">http://lists.puredata.info/____listinfo/pd-list</a>
<<a href="http://lists.puredata.info/__listinfo/pd-list" target="_blank">http://lists.puredata.info/__listinfo/pd-list</a>>
<<a href="http://lists.puredata.info/__listinfo/pd-list" target="_blank">http://lists.puredata.info/__listinfo/pd-list</a>
<<a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a>>><span><br>
<br>
<br>
<br>
<br>
_________________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>
<mailto:<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>>
mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/__listinfo/pd-list" target="_blank">http://lists.puredata.info/__listinfo/pd-list</a>
<<a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a>><br>
<br>
<br>
_________________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>
<mailto:<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a>>
mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/__listinfo/pd-list" target="_blank">http://lists.puredata.info/__listinfo/pd-list</a>
<<a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a>><br>
<br>
<br>
</span></blockquote>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div>