Hi everyone,

In the following patch, i simply need to get the duration between two attacks.

What puzzles me is that I often get the exact same value twice in my array. It happens whether I use fiddle~ or bonk~. Oneshot does exclude the values under 220, but why am I getting the same value twice? It seems to happen only for low values, close to 220. I know how to solve this, using [change], but still, I'd like to understand, what am I doing wrong?

Thanks

Lucien

@LucienR The problem is that [trigger] is sending bangs to the right and left inlets of [timer] almost instantaneously. Just curious, what values are you getting? I'd imagine they'd be pretty low.

I'm not too familiar with the second outlet of [fiddle~] but it sounds like it just outputs a bang when the amplitude level of an incoming signal exceeds an arbitrary threshold ($1, in your patch). Does it also report when volume has receded back below this threshold? In other words, you have setup your patch quite nicely to detect an attack event, but I'm not sure how you are getting duration.

Here's what I would do:

Maybe this is what [fiddle~] does, but in this diagram, I am taking the rms* of an incoming signal, converting it into decibels, and then checking with [> o.5] to see if these values go over a certain threshold. If yes, output 1, else 0. The [* 100] is just to scale up the values from [env~] and [dbtorms]to make them easier to read (they are really low).

*rms = root mean sqaure. I don't know the weird math behind it, but as I understand it, taking the rms means to take the average of an incoming signal over a short period of time rather than an instantaneous peak. In other words, rms does a good job at representing actual perceived volume level, which is very useful when grabbing real-time microphone input. It cuts down on weird triggering errors.

Hi,
Thanks for your answer, but the way I use trigger and timer is fine, I get correct values.

@LucienR ah ok I guess I am confused about your problem. Couldn't you add another [timer] to get times between consecutive attacks?

I actually get correct durations between consecutive attacks. The only problem is that I sometimes get the same value twice.

@LucienR I also do not understand why you are having troubles with your patch above, it seems perfectly patched to me. Maybe these repeated numbers are simply a coincidence -- or rather something characteristic of the signal you are using -- and not a problem with your patch. You can also try substituting the whole [oneshot] construction (together with the [clear(, [delay] and [220( part) by a single [ignore 220]. The [ignore] object does exactly what you want: it ignores any data arriving sooner than its argument in miliseconds from the last received data. Note that this object does not work with bangs, but you can simply convert a bang into any number using your favourite method (banging a [1( or a [t 1] for instance) and do the opposite to convert it back into a bang before the [timer].

Hope this helps,
Gilberto

Thanks Gilberto,
I didn't know the [ignore] object, I'll try it.
Anyway I simply solved this with [change], so I was just asking this out of curiosity.
Lucien

Hi Lucien,

The thing is that [change] will ignore any two consecutive numbers regardless if they are caused by some issue with your patch (that is, if it's wrongly outputting twice the result for some unknown reason) but also if these identical numbers are coincidences: e.g., if you have three notes spaced exactly 1003 ms from each other, [fiddle~] will output three bangs spaced in the same interval and so the last attack will be ignored. Try using [ignore] and see how it goes. If it also display the same behaviour as your first patch, then I'd strongly suspect that the same intervals are part of the signal itself and using [change] will lead to loss of information.

Cheers!
Gilberto