[vline~] is "exact" whereas [tabwrite~] starts at the next block
border?
If [tabwrite~] starts at the next block wouldn't it cut the beginning
of the ramp?
_______________
| / |
| / |
| / |
|/ |
| |
|______________|
but it does that : _______________ | / | | / | | / | | / | | / | |___/___________|
On Oct 4, 2005, at 12:19 PM, Urs Liska wrote:
Do I remember correctly (from the documentation or the help files)
that [vline~] is "exact" whereas [tabwrite~] starts at the next block
border? Maybe the resetting of the [phasor~] Frank tried also takes
place at the block border, which of course would lead to a seemingly
correct result of the [phasor~]'s output starting exactly at the
beginning of the array.This is (still?) quite over my head but maybe my comment could help
bring anybody else on the right track...Best Urs
Roman Haefeli schrieb:
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'
- 'shoud be executed at sample 23 of the block')? if yes, which objs,
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list-- Urs Liska Glümerstr. 5 D-79102 Freiburg
www.graft-music.com www.suonomobile.de
[Pd 0.39.0, WinXP]
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list