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
#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;
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
