help - schmitt trigger

I am trying to follow a clock signal and only need to look at it when the signal changes. schmitt catches the signal going high but seems to ignore it going low

That would indicate it the input signal is not going low enough to pass the hysteresis point or you have thresholds set wrong. Is this using dsp::SchmittTrigger?

yes, using dsp::SchmittTrigger. have not changed the thresholds

SchmittTrigger’s process function will only return true when getting triggered, you’ll have to implement catching the moment it goes low. You can check its state or write your own trigger.

OK so looking at the code, if you don’t supply thresholds, 1 volt is used for high and 0 volts for low. What is the range of the input voltage?

I had +5 and -5, then +10 and zero, neither worked

I always use 1v and 2v. 0v seems like an odd choice, as an “analog” clock would take infinitely long to get to zero (if it was say 0v to 5v).

using an lfo as a test source.

Can you show us the code you are using the SchmittTrigger in?

+1 on what Squinky Labs just stated. In hardware modules, the low trigger point is never usually zero.

    if (clock.process(inputs[CLOCK_INPUT].getVoltage())) {
	int cloc=inputs[CLOCK_INPUT].getVoltage();
        outputs[CLOCK_OUTPUT].setVoltage(cloc);
	lights[ENABLED_LIGHT].value = cloc;
    }

You need to set the output when the trigger is low, at the moment you are only ever setting it when it is high

you mean like add an else after that if? Also, make sure the input LFO is bipolar if you use the 0V default. Although that’s probably not it.

Something like this:

   float cloc = (inputs[CLOCK_INPUT].getVoltage();
   if (clock.process(cloc) {
        outputs[CLOCK_OUTPUT].setVoltage(cloc);
	lights[ENABLED_LIGHT].value =1.0f;;
   }
   else {
        outputs[CLOCK_OUTPUT].setVoltage(0.0f);
	lights[ENABLED_LIGHT].value = 0.0f;
   }
1 Like

I think I have missunderstood the purpose of schmitt trigger. I thought it would only trigger when the value changed, and always trigger when the value changed. is there a function llike that ?

I don’t quite understand what you are trying to achieve. I thought you wanted to output the value of the clock input only when it is determined to be “high”. Of that is the case, you still need to set the value to what you want it to be when the clock input is low. Outputs need their values explicitly set on every sample as they retain their values until you change and if you don’t set the value each sample, they can lose their values when a cable is connected/disconnected.

ah, some sort of edge trigger. I haven’t run into one in the sdk, but it’s easy enough to write one.

I have one, but it (by design) only triggers on a low to high edge: SquinkyVCV/GateTrigger.h at main · squinkylabs/SquinkyVCV · GitHub

Sounds similar to my GateProcessor that I use to find leading/trailing edges.

my theory was, to minimize cpu usage, only execute code if the value has changed from its previous state. so when it goes high, my code executes. while it stays high my code does nothing. when it goes low my code executes…

I use something like this

It’s like a schmittrigger but it gives back it’s state when updated which can be 4 different states.

States go like Up → Pressed → Down → Released → Up

Pressed and Released only happen for a single frame, this is where you want to do your thing.

Which might be confusing if you think about the signal but I had a button in mind which can be pressed by gate signals, so up means the button is up.

#define RELEASED -1
#define UP 0
#define DOWN 1
#define PRESSED 2

struct TriggerSwitch{
  bool down =false;
  int state = UP;
  float threshold = 0.1f;
  int update(float v){
     if(v > threshold){
      if(!down){
        down = true;
        state = PRESSED;
      }else
        state = DOWN;
     }else if(v <= threshold && down){
      down = false;
      state = RELEASED;
     }else{
      state = UP;
     }
     return state;
  }
  TriggerSwitch(){
  }
};

I can tell you from experience that it will most certainly reduce CPU usage however you will experience issues when cables are connected/removed from the output.

If you are concerned about performance, have a look at the document Squinky Labs produced on writing efficient plugins (I can’t remember where it is, perhaps he will post a link for you).