hello

i had a look at my test-patch again and: there definetely _is_ a drift over time. i am very confused, cause i tested it several times and i was really sure, that behaviour of [tabwrite~] must have changed. i even tested with older versions of pd to make sure, that behaviour was different before. anyway, when i tested again with my actual pd, i noticed a drift over time again. i can't recall exactly, where i got that pd-version from (from miller's site or from cvs), that didn't show any timedrift, but it is very likely, that i recompiled pd in the meantime. am i a victim of a strange fata morgana kind of thing, or is there effectively a version of pd around with different [tabwrite~]-behaviour?

roman

On Fri, 2007-03-30 at 13:10 +0200, Roman Haefeli wrote:

hello all

i stumbled across a new (and very appreciated!) behaviour of [tabwrite~].

in previous versions of pd (< 0.40), when banged, [tabwrite~] started to record on the next block-boundary. when used together with a [metro]/[del]-[vline~] construction, this lead to a time shift, because [vline~] started the ramp somewhere between block-boundaries.

now (at least in pd 0.40.2) i noticed, that this behaviour has changed and [tabwrite~] seems to use the same scheduler (or however this mechanism is called) like [vline~]. i couldn't find any documentation about that in the release notes.

i wonder, if more objects have changed their behaviour. i am especially interested to know, if and which osclillator-objects also changed behaviour for their phase-inlets. this would make it possible to use [vline~] as a ramp generator while staying synched for each trigger. (e.g. interesting for creating bassdrums).

i attached a patch to show the behaviour of [tabwrite~ ]

roman _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de