Actually, I think (it's not the first time I say that, I guess), that all inlets of object classes, which have signal outlets (or all objects that convert from message domain to signal domain) should take the exact timing into account.
Yeah! No object should be left out! Every single object should take exact timing into accounts, or at the very least, have a "v" counterpart that does (I guess the objects that don't are faster, so when sub-block accuracy is not needed one may actually prefer the "inaccurate" version).
By the way, you say all those objects that convert from message to signal domain. Why not the other way round too? I always wished there was a [vthreshold~] for example. Or is it physically impossible? I mean perhaps you get the information one block too late?
Also it is cumbersome to have to know which object classes support exact timing and which not.
Absolutely!
thanks m.
On Fri, 2010-04-16 at 16:00 +0200, Matteo Sisti Sette wrote:
Actually, I think (it's not the first time I say that, I guess), that all inlets of object classes, which have signal outlets (or all objects that convert from message domain to signal domain) should take the exact timing into account.
Yeah! No object should be left out! Every single object should take exact timing into accounts, or at the very least, have a "v" counterpart that does (I guess the objects that don't are faster, so when sub-block accuracy is not needed one may actually prefer the "inaccurate" version).
Actually, the most cases (such as [*~],the left inleft of [osc~]/[phasor~] etc.) can be covered with a - let's call it [vsig~] abstraction based on [vline~].
By the way, you say all those objects that convert from message to signal domain. Why not the other way round too? I always wished there was a [vthreshold~] for example.
Right. There is [vsnapshot~], which does something similar, though it's not truely converting from audio domain to message domain, since only the resulting value is taken from the audio domain, whereas the timing still comes from the message domain. From what I know, the message comes one block late.
Or is it physically impossible? I mean perhaps you get the information one block too late?
I think so. Can someone confirm who knows?
Roman
hi
Right. There is [vsnapshot~], which does something similar, though it's
not truely converting from audio domain to message domain, since only the resulting value is taken from the audio domain, whereas the timing still comes from the message domain. From what I know, the message comes one block late.
but you can bang vsnapshot~ faster than the block rate and it seems it works fine. so there must be no one-block delay.
alabala
ypatios escribió:
There is [vsnapshot~] [...] From what I know, the message comes one block late.
but you can bang vsnapshot~ faster than the block rate and it seems it works fine. so there must be no one-block delay.
I don't know whether the messages come a block later or not, but the fact you can bang more than once per block and not loose messages is not incompatible with the possibility that there is a one-block delay: the messages can come "accumulated" with the correct values and timestamps but all one-block late... like out of a one-block pipe...
what if a timer between bang and vsnapshot's reaction shows 0?
ypatios escribió:
what if a timer between bang and vsnapshot's reaction shows 0?
I'm not sure whether this proves or disproves the one-block-delay hypothesis. Experts of the insides of how Pd's data/dsp processing loop works can certainly answer on that - and I'm very curious too
-
Matteo Sisti Sette -
Roman Haefeli -
ypatios