[PD] is there a way to send a bang precisely when a sample is looped using tabread4~?

[Ivica Ico Bukvic]

On 07/15/2012 07:43 PM, Funs Seelen wrote:
> You don't need information from [tabread4~ ], but from [phasor~] to do 
> that. The value of phasor~ increases except for one moment, the moment 
> your new loop starts. So check while comparing each current sample [n] 
> to the one before [n-1] for the moment [n] < [n-1]. You can do that 
> with [expr~ if($v1<$v2, 1, 0)] and do for example the following:
>
> [expr~ if($v1<$v2, 1, 0)]
> |
> [env~]
> |
> [== 0]
> |
> [change]
> |
> [sel 0]
> |
> [bng]
>
> Connect [phasor~] to the left inlet of [expr~].
> Connect [phasor~] also to [biquad~ 0 0 0 1 0] or if you have zexy to 
> [z~] and connect its outlet to the right inlet of [expr~].
>
> There might be other possibilities but this should work.
>
This is still limited to the signal vector size inside pd even at the 
smallest env~ buffer (which is also incredibly CPU intensive). In other 
words, pd by default does everything in 64-byte chunks (unless one 
manually alters this behaviour which with lower buffers results in a 
rapid increase in CPU overhead). Furthermore, if you do this with a 
high-freq phasor that completes its period within 64 bytes, you will 
begin to miss leaps that expr~ is searching for.

As an alternative, you could use disis_phasor~ external which has a 
second outlet and outputs a bang when it completes a period. This, while 
definitely as accurate as it gets within the constraints of the sig_vs, 
suffers from same limitations unless the signal vector is lowered. In 
other words, the bang will come guarranteed within the 64-byte window. 
But there is no guarantee that it will happen right on the 0th sample or 
that it will not periods that are smaller than 64-byte chunks.

If per-sample control is what you crave, you can either mess with sig_vs 
message to pd (or whatever it is, can't remember it off top my head) and 
deal with the cpu overhead, design your control entirely in signal land, 
or go with something like chuck programming language (which also has a 
considerably higher cpu footprint for the same reasons).

HTH

-- 
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net