Andy

I have a situation where I am testing a scenario using if statements - sending out 1 = true, 0 = false.

This all works nicely but.... there is an extremely fast change of state that is so fast it is not actually visible when looking at a number box stuck on the end of my conditional.

I know why this is happening and it does not seem to be something I can change earlier in the chain (I have already ensured that the two items to be tested are sent through at the same instance).

I can't think of any objects that filter out fast changes like this. Can anybody suggest one or a way to stop this happening?

This all works nicely but.... there is an extremely fast change of state that is so fast it is not actually visible when looking at a number box stuck on the end of my conditional. 

I can't think of any objects that filter out fast changes like this. Can anybody suggest one or a way to stop this happening? 

ignore-fast-logic-test-changes

I'm not sure what you want: fast changes to be filtered out or kept and shown in a way you can visualise?

I'm not sure what you want: fast changes to be filtered out or kept  and shown in a way you can visualise?

Do you want fast changes to be ignored? If so, [pipe].

Do you want the most often occurring state? If so, average.

Do you just want to thin data? If so, [speedlim].

On Feb 4, 2008, at 12:31 PM, Andy Brennan wrote:

> I have a situation where I am testing a scenario using if statements 

> This all works nicely but.... there is an extremely fast change of 

> state that is so fast it is not actually visible when looking at a 

> number box stuck on the end of my conditional.

> I know why this is happening and it does not seem to be something I 

> can change earlier in the chain (I have already ensured that the two 

> items to be tested are sent through at the same instance).

> I can't think of any objects that filter out fast changes like this. 

> Can anybody suggest one or a way to stop this happening?

"The greatest of the changes that science has brought us is the acuity 

of change; the greatest novelty the extent of novelty."

>
> Hi,
>
> I have a situation where I am testing a scenario using if statements  
> - sending out 1 = true, 0 = false.
>
> This all works nicely but.... there is an extremely fast change of  
> state that is so fast it is not actually visible when looking at a  
> number box stuck on the end of my conditional.
>
> I know why this is happening and it does not seem to be something I  
> can change earlier in the chain (I have already ensured that the two  
> items to be tested are sent through at the same instance).
>
> I can't think of any objects that filter out fast changes like this.  
> Can anybody suggest one or a way to stop this happening?
>
> Thanks
>
> Andy

San Francisco, CA
Work: 857-544-3967
Email: bthrew (at) gmail (dot) com
IM: captogreadmore (AIM)
http://www.barrythrew.com

"The greatest of the changes that science has brought us is the acuity  
of change; the greatest novelty the extent of novelty."
- J. Robert Oppenheimer


Scratch that pipe suggestion. It doesn't work...which CHRIS MUIR SO 

KINDLY DISCOVERED UNDER THE GAZE OF HIS UNBLINKING EYE.

I was thinking of del, which resets its clock on each bang.

You could do this instead, but it might not be the behavior you are 

Scratch that pipe suggestion. It doesn't work...which CHRIS MUIR SO  
KINDLY DISCOVERED UNDER THE GAZE OF HIS UNBLINKING EYE.

You could do this instead, but it might not be the behavior you are  
looking for.

Sorry I thought I had been clear. What I mean by ignore, is to completely ignore the fact the event ever occurred.

What I want is for my system to ignore any change from 0 to 1 or 1 to 0 that occurs and then reverses itself within a given time threshold.

Things like pipe and delay don't stop events, they just postpone them from happening. What I want is total denial that the number ever changed - therefore the conditional result would remain constant - in the above case it should never move away from 0.

The only way I can tell that the change happens is because

b) a 'select 1' box produces a bang even though the number does not change.

Essentially I think I am wanting a reverse 'threshold' type object that instead of collating variables received within a given time, rejects them instead.

a) my patch is not doing what it should
b) a 'select 1' box produces a bang even though the number does not change.

Sorry. Actually I may see what you mean with the delay object. You can click it as many times as you like but only the most recent is passed - this may make it disregard the change.

you could time the events like this, which works quite well for most applications. Timing may fluctuate depending on your max settings.

Quote: Andy wrote on Mon, 04 February 2008 16:07

----------------------------------------------------

> Sorry I thought I had been clear. What I mean by ignore, is to completely ignore the fact the event ever occurred.

> What I want is for my system to ignore any change from 0 to 1 or 1 to 0 that occurs and then reverses itself within a given time threshold.

This request reminded me of the object jb.skeptic: don't "believe" input until it occurs n-times in a row. 

I have not used this personally, but sounds like what you need. And it is an abstraction so you could alter it if needed.

Quote: Andy wrote on Mon, 04 February 2008 16:07
----------------------------------------------------
> Sorry I thought I had been clear. What I mean by ignore, is to completely ignore the fact the event ever occurred.
>
> What I want is for my system to ignore any change from 0 to 1 or 1 to 0 that occurs and then reverses itself within a given time threshold.
>

This request reminded me of the object jb.skeptic: don't "believe" input until it occurs n-times in a row. http://www.greyfade.com/joe/maxmsp.html

This sort of filters the input. I think it would reject some of your 

unwanted changes. I've used techniques like this to reduce 

"chattering" on MIDI controllers, but not on a string of 0s and 1s. 

This sort of filters the input. I think it would reject some of your  
unwanted changes. I've used techniques like this to reduce  
"chattering" on MIDI controllers, but not on a string of 0s and 1s.  
I'm not sure it would be as effective.

My solution remains good with a slight modification.

On Feb 4, 2008, at 4:07 PM, Andy Brennan wrote:

> Sorry I thought I had been clear. What I mean by ignore, is to 

> completely ignore the fact the event ever occurred.

> What I want is for my system to ignore any change from 0 to 1 or 1 

> to 0 that occurs and then reverses itself within a given time 

> Things like pipe and delay don't stop events, they just postpone 

> them from happening. What I want is total denial that the number 

> ever changed - therefore the conditional result would remain 

> constant - in the above case it should never move away from 0.

> The only way I can tell that the change happens is because

> a) my patch is not doing what it should

> b) a 'select 1' box produces a bang even though the number does not 

> Essentially I think I am wanting a reverse 'threshold' type object 

> that instead of collating variables received within a given time, 

>
> Sorry I thought I had been clear. What I mean by ignore, is to  
> completely ignore the fact the event ever occurred.
>
> What I want is for my system to ignore any change from 0 to 1 or 1  
> to 0 that occurs and then reverses itself within a given time  
> threshold.
>
> for example
>
> change 1 - 0 to 1
> change 2 - 1 to 0
>
> Things like pipe and delay don't stop events, they just postpone  
> them from happening. What I want is total denial that the number  
> ever changed - therefore the conditional result would remain  
> constant - in the above case it should never move away from 0.
>
> The only way I can tell that the change happens is because
>
> a) my patch is not doing what it should
> b) a 'select 1' box produces a bang even though the number does not  
> change.
>
> Essentially I think I am wanting a reverse 'threshold' type object  
> that instead of collating variables received within a given time,  
> rejects them instead.
>
> Thanks
>
> Andy

this sort of works. It's not perfect though.

But does it get you a step closer to the solution?

>
> Sorry I thought I had been clear. What I mean by ignore, is to  
> completely ignore the fact the event ever occurred.
>
> What I want is for my system to ignore any change from 0 to 1 or 1  
> to 0 that occurs and then reverses itself within a given time  
> threshold.
>
> for example
>
> change 1 - 0 to 1
> change 2 - 1 to 0
>
> Things like pipe and delay don't stop events, they just postpone  
> them from happening. What I want is total denial that the number  
> ever changed - therefore the conditional result would remain  
> constant - in the above case it should never move away from 0.
>
> The only way I can tell that the change happens is because
>
> a) my patch is not doing what it should
> b) a 'select 1' box produces a bang even though the number does not  
> change.
>
> Essentially I think I am wanting a reverse 'threshold' type object  
> that instead of collating variables received within a given time,  
> rejects them instead.
>
> Thanks
>
> Andy


> My solution remains good with a slight modification.

I would guess he need the last value, not the first, which is even simpler:

(I have for that purpose also a slightly more complex abhaXion called 

firstlast in my collection to get both the first, the last and direction 

barry threw schrieb:
> My solution remains good with a slight modification.

(I have for that purpose also a slightly more complex abhaXion called 
firstlast in my collection to get both the first, the last and direction 
of change independently...)

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Thats exactly what I need it to do. Thanks Stefan.

If you're not familiar with the object, it only passes a bang through (from

the left inlet) after first receiving a bang in the right inlet.

I used it with a delay object sending a bang from the output to the right

inlet after a time delay of a few milliseconds. This means that it'll only

Just don't forget that it needs a bang in the right inlet before the left,

> Thats exactly what I need it to do. Thanks Stefan.

So you technically need to "debounce" ?
Try onebang
If you're not familiar with the object, it only passes a bang through (from
the left inlet) after first receiving a bang in the right inlet.
I used it with a delay object sending a bang from the output to the right
inlet after a time delay of a few milliseconds. This means that it'll only
output bangs a certain time space apart.

Just don't forget that it needs a bang in the right inlet before the left,
so a loadbang may be necessary.

On 05/02/2008, Andy Brennan  wrote:
>
>
> Thats exactly what I need it to do. Thanks Stefan.
>
> Andy
>

A onebang is not appropriate for the problem as it needs to be reset each time. This may mean it blocks wanted information as well as quick change info. I think Stefan's solution works best as all the fast changes are ignored and the end result used.

Ignore fast Logic Test Changes