hi frank
i don't think that vline~ is off. i rather think it is more accurate (as it is said in helpfile), even more accurate than sample-accurate. i attached a patch, that should show the accuracy of vline~. it seems that vline~, when getting messages from a [del] or a [metro], knows to which time the bang 'is thought' to be executed.
my question is [to the devs]: how does vline~ get this information? is the there something like a timestamp attached to the messages from [del] and [metro] (like: 'bang'
besides [metro] and [del], do attach this info? on the other hand, which obj (besides [vline~]) do consider this info?
(i could be well, that i am asking the wrong questions, since i don't know much about the pd-internals)
cheers roman
"Frank Barknecht" wrote:
Hallo, Enrique Erne hat gesagt: // Enrique Erne wrote:
triggering [0, 1 2 0( -> [vline~] by [bang( or [bng] and writing its outlet to an array with [tabwrite~] gives me a line starting at the beginning of the array.
doing the same with a [metro] instead [bng] or [bang( gives me start position 'jumping' around . it seems that the [vline~] starts too late (after the [tabwrite~] has started) .
I think you have found a bug. However I have no idea, where. I would suppose it's somewhere in [vline~]. I noted, that vline~'s starting point seems to be off in an area between 0 and 64 samples, which is exactly Pd's default block size. If you change the blocksize like in [block~ 128] then [vline~] is off up to 128 samples. Somewhere there seems to be a mismatch between the time, the metro bangs arrive at [tabwrite~] and the time internal to [vline~]. I also tested resetting the phase of a [phasor~ 500] and recording this into a table. The [phasor~] gets recorded correctly starting at array position 0. So it's only [vline~] that's off.
Ciao