hi list,
what is the time resolution on non-signal-domain? milliseconds or even higher?
thanks for info-
mirko
Psssst! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine für Alle: http://www.gmx.net/de/go/messenger03
Hi Mirko,
it is "logical time", which means that PD will try to process non-signal messages as fast as the CPU will let it. This explains why certain structures like a counter which uses the hot inlet of [f] instead of the cold one will lock up PD.
best, D.
Mirko Maier wrote:
hi list,
what is the time resolution on non-signal-domain? milliseconds or even higher?
thanks for info-
mirko
Mirko Maier wrote:
hi list,
what is the time resolution on non-signal-domain? milliseconds or even higher?
it's milliseconds expressed in double precision floating point. double precision is only available internally, so on the patch level you have "only" single precision.
fgamsdr IOhannes
So where does logical time come into this then? Was I mistaken? Did I misread whichever thread it was a while ago discussing that?
D.
IOhannes m zmoelnig wrote:
Mirko Maier wrote:
hi list,
what is the time resolution on non-signal-domain? milliseconds or even higher?
it's milliseconds expressed in double precision floating point. double precision is only available internally, so on the patch level you have "only" single precision.
Derek Holzer wrote:
So where does logical time come into this then? Was I mistaken? Did I misread whichever thread it was a while ago discussing that?
logical time comes in when you try to convert from messages to the "outside world" (e.g. audio signals)
whether the logical time is preserved depends on the converter (e.g. [vline~] vs [line~])
btw, this has nothing to do with message loops (your "running hot" example)
fgmasdr IOhannes
PS: it seems you haven't tried to build a "hot counter" for some time :-)
-
Derek Holzer -
IOhannes m zmoelnig -
Mirko Maier