[PD] maximum "control rate" in Pd
Alexandre Torres Porres
porres at gmail.com
Thu Mar 12 18:25:33 CET 2015
> 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 at 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 at chnry.net <mailto:
>> ch at 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 at chnry.net <mailto:
>> ch at chnry.net> <mailto:ch at chnry.net <mailto:ch at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> <mailto:
>> Pd-list at lists.iem.at <mailto:Pd-list at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> <mailto:
>> Pd-list at lists.iem.at <mailto:Pd-list at 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 at lists.iem.at <mailto:Pd-list at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/__
>> listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150312/f5435341/attachment-0001.html>
More information about the Pd-list
mailing list