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