The basic idea of the module is to allow users to create a vector of “active ratios” by which to multiply the incoming bpm, and then scan through that vector. The commented out section of code works as intended, adding and removing index values for the array of ratios. But it’s called in every frame because it’s in the function that returns what ratio to use. It would be better performance-wise to update the vector only when a new ratio button or input is activated, which is what the code in process() attempts to achieve.
buttonsOn and inputsOn in process() are working, but buttonsOff and inputsOff are not. As I understand it, when they process 0.f from a High state, they should return an UNTRIGGERED event, which = -1, which should call vector.erase(). But the vector just keeps getting bigger as I turn buttons or inputs on and off, which leads me to believe I’m not implementing schmittTrigger.process() correctly.
The intention is that it should only fire if the button is off and also the input schmittTrigger is NOT in a high state. That is, if the button is off, but the input is on, it should not remove the value, and vice versa.
so my other thought is i often use separate triggers for upswing vs downswing. but i’m not sure you are using the rack schmidt trigger since I don’t see processEvent on that in my code base (but I may be behind a bit).
T process(T in, T lowThreshold = 0.f, T highThreshold = 1.f) {
T on = (in >= highThreshold);
T off = (in <= lowThreshold);
T triggered = ~state & on;
state = on | (state & ~off);
return triggered;
}
this needs different args for upswing than downswing
Here’s the code for processEvent(). It’s basically the same as process(), except it returns an event instead of a bool. The events are TRIGGERED = 1, UNTRIGGERED = -1, and NONE = 0. I think that means the same trigger can be for both upswing and downswing, returning the trigger at the moment of change, while also holding a low or high state.
I figured out the solution! The problem was casting the processEvent to bools, and then having two separate bools for on and off. By treating the return as its correct return type, which is SchmittTrigger::Event, you get either value from a single processEvent. I hope that makes sense.