[PD] new behaviour of [tabwrite~]

Roman Haefeli reduzierer at yahoo.de
Fri Mar 30 13:10:27 CEST 2007


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
-------------- next part --------------
#N canvas 714 193 654 317 10;
#X obj 96 131 vline~;
#X obj 50 109 b;
#X msg 97 101 0 \, 1 2 \, 0.5 1 3;
#X obj 53 56 metro 300;
#X obj 35 218 table graph 300;
#X obj 32 184 tabwrite~ graph;
#X obj 53 10 loadbang;
#X obj 54 34 1;
#X text 223 19 have a look at the table.;
#X text 221 81 in 0.40.2 it is stable;
#X text 217 48 in pd < 0.4 the ramp shifts over time.;
#X connect 0 0 5 0;
#X connect 1 0 5 0;
#X connect 2 0 0 0;
#X connect 3 0 2 0;
#X connect 3 0 1 0;
#X connect 6 0 7 0;
#X connect 7 0 3 0;


More information about the Pd-list mailing list