Hallo, Peter Plessas hat gesagt: // Peter Plessas wrote: > i have a question regarding timing in Pd: > > I understand that messages to tilde objects just get passed to the DSP > tree within DSP blocks. > > How about the reverse? > > Found out that snapshot~ is returning the last sample of the last block > during which it got banged. This is fine, since it is the sample value > most closely to the output of the result. > > Now when i use the following setup: > > [bang~] > | > | > [t b b] > | | > | | > [timer] > > i get a minimum logical time of 1.45 msec (aquivalent to 64samples at > 44.1 kHz) even when i use a blocksize of [block~ 32].
I think, bang~ should bang after each block, so with [block~ 32] it should bang every 32 samples. But it seems to have a lower limit of 64 samples. Don't know why. In general, Pd has like to times: One is the time realm of clock-delayed messages, i.e. everything that originates in a clock objects like metro, delay, pipe, qlist, etc. Clock delayed messages have sub-sample accuracy. This is achieved by "tagging" each normal message with a time tag, similar to the old time tagged triggers in t3_lib. The tags for clocks are invisible, though. To convert dsp signals to clock-delayed messages you must use [vsnapshot~], but [snapshot~]. It will give you the value of a sample even when bang'ed somewhere in the middle of a block. Note that you cannot use this value to modify other samples during the same block! Because when the message comes out of [vsnapshot~], this block has already been calculated. So you can only start to use the value to modify the next block's content. Ciao -- Frank _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list