Potentially Stupid Question re: [>]

    Jul 18 2012 | 11:43 am
    So I'm trying to do some kind of very basic frequency analysis. I want the output of [meter~] to trigger a bang if the level goes above a given number (0.2 say). I've got the following:
    It's very basic, but [>] isn't playing ball. I've set it so that it should only accept numbers over 0.2 from a range of 0-0.25, but it just goes mad and sends bangs whenever it receives *any* number in that range. Am I missing something really basic? I'm not sure if I should be using [>~] instead. I'm guessing not since the signal has been converted to numbers by the time it reaches [>]...

    • Jul 18 2012 | 12:32 pm
      It might genrally be easier to use [thresh~] and [scale~] for what you are trying to do.
      I've tried using the output of meters before, and it never quite works out too well.
    • Jul 18 2012 | 1:46 pm
      That seems to be doing the trick. Thanks!
    • Jul 18 2012 | 2:53 pm
      i haven't had a look at your patch but it sounds like you miss this: [> 0.2] [change] [sel 1]
      since > is outputting logic values (0, 1) and not bangs if true, if you hook up a button at will light up all the time. I wouldn't suggest doing it exactly the way i described, but i *think* that's whats wrong with your construction and wanted to correct this instead of suggesting something very different. Just for you to recognise your mistake. Cheers!
      edit: [print] is your friend!
    • Jul 19 2012 | 6:26 pm
      You really want to use a two-stage threshold for this (i.e. thresh~) because it will debounce your output.
      Imagine this case: threshold at 0.2 and you have a stream of values that are rapidly fluctuating between 0.19 and 0.21. Is this really a series of on/offs? Probably not, but it's going to be classified as one if you use a simple comparator (>).
      A two-stage threshold simply says "it's got to go above or below both values in order to change states". This means that in the above example it would be on (if 0.2 is your upper threshold and maybe your lower threshold is 0.1)
      In practical terms, you can use dbtoa to devise your thresholds, so you can say things like: it has to increase by 6 dB to be a new attack.
      If you're looking to detect attacks, you may (or may not) find my EnvelopeShaper device handy.
    • Jul 22 2012 | 4:19 pm
      Peter, I don't really understand your post. I think it might be because I don't entirely understand thresh~ though. If I set the low threshold to 0.1 and the high to 0.2, it's then letting through values that are only between 0.1 and 0.2, right? I've had a quick look at dbtoa, dbtoa~ and your EnvelopeShaper, but I'm not sure where I would put those, or indeed if I would even need them in the first place.
      Basically, I just want to detect attacks above a certain level (low threshold on thresh~?), to then trigger a bang which I can use to do whatever.
      On a side note, I find Max 6 help patches to be decidedly unhelpful (e.g. thresh~).
    • Jul 25 2012 | 6:50 pm
      No, it's a little different. A value can only become on when it goes above both values. It can only change to off when it goes below both values.
      I think the thing that you may be missing is that you need to smooth out your input signal. Meter~ is doing this for you already, by returning the peak value every n ms; the catch is that it's doing it based on the peak, and it's outputting at control rather than signal rate.
      Try this patch and see where it gets you: