[PD] triggering vline~ compared with line~

[Enrique Erne]

> [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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->  
> http://lists.puredata.info/listinfo/pd-list
>