Look closely… the unwanted triggers are occurring before the signal goes down.
Therefore the cause of the unwanted triggers cannot have anything to do with the signal going down. It is completely impossible for the value change at 0.6 sec to go back and retroactively cause something to happen at 0.55xxxx sec.
OK, there’s an unwanted trigger between 0.5 and 0.6 sec.
If you assign the plotter object to a variable (instead of just displaying it and throwing it away), then you can get access to the data.
// also added spaces for readability
(
p = {
var base = LFPulse.kr(2, 0.3).lag(0.1);
var up = (Slope.kr(base) * 0.002).max(0); // filtering raising slopes
var trig = Trig.kr(up); // should only trigger when the signal goes up.
[base, up, Env.perc(0, 0.2).kr(0, trig)]; // Evn.perc is used to visualise the trigger
}.plot(2);
)
// extract 0.5-0.6 sec from the slope plot
// (this was my 3rd try: needed asInteger, and it's a kr plot --> / 64)
a = p.value[1][(0.5 * s.sampleRate / 64).asInteger .. (0.6 * s.sampleRate / 64).asInteger];
As quoted, the key is “nonpositive to positive transition” – we’ve got the data, so we can query the data for that condition.
// look for nonpos --> pos
(
z = Array.new;
a.doAdjacentPairs { |a, b, i|
if(a <= 0 and: { b > 0 }) {
z = z.add(i);
}
};
z
)
-> [ 46, 48, 50, 53, 56, 62 ]
// look at the slope data for this segment
a[46 .. 62]
-> [ 0.0, 8.9406974268513e-08, 0.0, 8.9406974268513e-08, 0.0, 8.9406974268513e-08, 0.0, 0.0, 8.9406974268513e-08, 0.0, 0.0, 8.9406974268513e-08, 0.0, 0.0, 0.0, 0.0, 0.0 ]
// and, for giggles, go back to the original LFPulse
(
var offset = (0.5 * s.sampleRate / 64).asInteger;
p.value[0][46 + offset .. 62 + offset];
)
-> [ 0.99999958276749, 0.99999964237213, 0.99999964237213, 0.99999970197678, 0.99999970197678, 0.99999976158142, 0.99999976158142, 0.99999976158142, 0.99999982118607, 0.99999982118607, 0.99999982118607, 0.99999988079071, 0.99999988079071, 0.99999988079071, 0.99999988079071, 0.99999988079071, 0.99999988079071 ]
So we find, when we zoom in on the data, that Lag, as it approaches the target value, slows down so much that some successive samples are equal, producing slope == 0 momentarily. If you are then basing a trigger directly off of the slope, then you will get spurious triggers immediately following these 0s.
One take away here is that it hurts your ability to diagnose a problem by just making a big plot and saying “well, the plot looks OK.” The plot does not have enough visual resolution for some problems. In this case, if there’s a trigger, then there must be a nonpositive to positive transition, even if you don’t see it.
… implicitly raising the slope threshold to 0.5… but in that case, one could just write the threshold directly: (Slope.kr(base) * 0.02) >= 0.01
– the offending slope values are many orders of magnitude smaller than this. round
obscures what is really going on.
In any case, for the original problem: A Schmitt trigger (which SC misspells “Schmidt,” well, we’re stuck with that typo now) triggers when the signal goes above a set level, and it will not trigger again until the signal goes below a different threshold and then above the first threshold again. This “debounces” the triggers when the signal is close to the threshold. You might try that.
hjh