dear list
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) .
[metro]
|
| [0, 1 2 0(
| |
| [vline~]
| /
[tabwrite~]
I can't understand this behaviour and why a [line~] does start at the beginning (t3_line~ also).
thanks for education :-) Enrique
example compares [line~] and [vline~]
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
Frank Barknecht _ ______footils.org_ __goto10.org__
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
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
[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
hi eni, hi urs
On Tue, 4 Oct 2005 13:24:27 +0200 Enrique Erne pd@mild.ch wrote:
[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?
no, because [tabwrite~] starts recording at sample 0 of the block and [vline~] starts the ramp at sample N, where 0 <= N <= BLOCKSIZE. but i still wonder, how does [vline~] know, where to start the ramp? CK told me, that there isn't a thing like a 'timestamp' in the code of [delay].
another idea: is [vline~] quantized to 1ms?
roman
Was denken Sie über E-Mail? Wir hören auf Ihre Meinung: http://surveylink.yahoo.com/wix/p0379378.aspx
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
no, because [tabwrite~] starts recording at sample 0 of the block and [vline~] starts the ramp at sample N, where 0 <= N <= BLOCKSIZE.
Hm, somehow I assumed that tabwrite~ would not be block-quantized, but that it instead was time-accurate. Well,but if tabwrite~ records block-aligned, then the behaviour of vline~ inside the patch is fully correct. However somehow it frightens me, that setting the phase of a phasor~ is not time-accurate, but block-aligned as well ...
but i still wonder, how does [vline~] know, where to start the ramp?
It looks at the clock.
vline~ gets Pd's notion of "now" (its "logical time") using clock_gettimesince() which gives the: "elapsed time in milliseconds since the given system time" (m_sched.c)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hm, somehow I assumed that tabwrite~ would not be block-quantized, but that it instead was time-accurate. Well,but if tabwrite~ records block-aligned, then the behaviour of vline~ inside the patch is fully correct. However somehow it frightens me, that setting the phase of a phasor~ is not time-accurate, but block-aligned as well ...
messages in pd are basically all block-quantized. (even t3_messages are (this is: appear in the system) block-quantized, but they hold an additional time-stamp that tells the t3~objects a sample accurate offset)
an object can emit a message during dsp-processing (this is: _not_ aligned to the block), but it shouldn't do so because a) it circumvents pd's scheduler and all the tricks built in to provide a click-free stream of sounds and b) this is still not sample accurate, because whatever ~-object it tries to influence has either already finished processing (so the message will modify the next block) or it is still waiting for processing (so the block hasn't yet started and the message will modify the "current block to come"); there is one notable exception: if the message is fed back to the object that emitted it, it _could_ make a sample-accurate change: however, because of the object's optimization in the dsp_routine() it is likely that it will have an effect not before the next block.
mfg.asdr. IOhannes
Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
messages in pd are basically all block-quantized.
Then how does [vline~] know, that the bang of the [metro] arrived in the middle of a block?
because it calculates the logical time (which - by definition - is exact) and maps that to "sample time". using the logical time is equivalent to timestamping.
mfg.asdr IOhannes
IOhannes m zmoelnig wrote:
because it calculates the logical time (which - by definition - is exact) and maps that to "sample time".
which should read: it queries the logical time (from the pd scheduler) and calculates the "sample time" from it. (i guess this is more clear)
mfg.asd.r IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
because it calculates the logical time (which - by definition - is exact) and maps that to "sample time".
which should read: it queries the logical time (from the pd scheduler) and calculates the "sample time" from it.
In the example posted, there is a [t b b] attached to the metro, which first bangs the tabwrite~ then the message to vline~. As messages are block aligned, the [t b b] might bang at block boundaries. Still vline~ (seems to] correctly follow the [metro 500], which might not always bang on block boundaries, as [metro] is driven by Pd's logical time. I still wonder, how vline~ knows, when in time the [t b b]-bang arrived.
(Currently confused listening to "Bangin' Tough" by "New Bangs On The Block")
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
In the example posted, there is a [t b b] attached to the metro, which first bangs the tabwrite~ then the message to vline~. As messages are block aligned, the [t b b] might bang at block boundaries. Still vline~ (seems to] correctly follow the [metro 500], which might not always bang on block boundaries, as [metro] is driven by Pd's logical time. I still wonder, how vline~ knows, when in time the [t b b]-bang arrived.
Krzysztof answered this for me in another thread. Attached is a little play with a [del] that's actually behaving subblock accurate.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Enrique Erne -
Frank Barknecht -
IOhannes m zmoelnig -
Roman Haefeli -
Urs Liska