v1025kernel

I'm trying to write an if and only if statement to trigger a button. I have three random values coming in and I want the button to turn on only if the three values are present at the same time.

Button On: 3,6,7 or 3,7,6 or 6,3,7 or 6,7,3 or 7,6,3 or 7,3,6. 

NOT when just a 3, or 6, or 7 is present [which is what's happening now]

I'm trying to use the if command with &&, but I don't think it's working.

I'm trying to write an if and only if statement to trigger a button.  I have three random values coming in and I want the button to turn on only if the three values are present at the same time.

Example: 
Random Number: 1-10, 
Button On: 3,6,7 or 3,7,6 or 6,3,7 or 6,7,3 or 7,6,3 or 7,3,6.  
NOT when just a 3, or 6, or 7 is present [which is what's happening now]

if-and-only-if-statement

try using three == objects, then two && objects. would put it together right now, but i'm at a different computer and don't have max available. but it should be easy enough.

Here are two examples, one with the if object, one with the match object

Your patch is something of a nightmare, I don't know if anybody is going to debug it for you. But a couple of things to look at.

- Are you sure there are no right-to-left issues, esp. w/r/t your pack objects?

- Testing floats for equality is Bad Karma. Two floats may be very very close, but an equality test will evaluate to false. Floats are almost never equal.

- Since you're starting off with ints, you would be *much* better off to stay in the int domain. There's no point in testing ( = 27.5 && $f1 = 28 && $i1

- Better still, use [split 28 53]. Isn't that easier? Use floats if you must, but split is your friend.

Using the above will simplify your patch enormously, making it easier to debug.

After writing the above, my gut instinct is that it's some of the tests for float equality that are breaking your logic.

I also notice you're generating frequencies with a flat distribution, although pitch perception is logarithmic. You will get far more high pitches than low pitches. Is that really what you want?

If it *is* what you want, you could use a negative exponential distribution to generate MIDI note numbers and do all your matching in the integer domain, and just convert to frequency before sending to cycle~ or whatever. Mtof will do the conversion, lp.expo will give you the exponential random numbers. Lp.expo is part of Litter Power Pro. You can also get a cheap approximation of the exponential distribution with lp.linnie from the Litter Starter Pack.

- Since you're starting off with ints, you would be *much* better off to stay in the int domain. There's no point in testing ( = 27.5 && $f1 = 28 && $i1 

The server just killed a more detailed response:-(

- Testing floats for equality is a recipe for disaster. Don't do it unless you understand digital floating point arithmetic. This is probably the bug in your patch.

- Most of your ifs would be more idiomatically done with the split object

- You're starting off with ints, you will be better off to do your tests in the int domain.

- There may or may not be right-to-left issues.

Finally: you're generating frequencies with a flat distribution, but pitch perception is logarithmic. In short, there will be more high pitches than low pitches.

If that is really what you want, you would be better off to generate MIDI note values with a negative exponential distribution, do your test in the int domain, and convert to frequencies with mtof just before you pass the values on to cycle~ or whatever.

For exponential distributions you can use lp.expo from Litter Power Pro. You can get a cheap (rough) approximation of a negative exponential distribution with lp.linnie from the Litter Starter Pack.

If that is really what you want, you would be better off to generate MIDI note values with a negative exponential distribution, do your test in the int domain, and convert to frequencies with mtof just  before you pass the values on to cycle~ or whatever.

I've put together a smaller problem example which if solved, should help me on the grander scale.

Like before, I'm using iff statement to identify major and minor triads. The problem is that only the minor a-c-e and a-e-c are identified. I've also included a version using only integer numbers, but the problem is the same.

*Also, what exactly is the 'right-to-left' issue?

I've put together a smaller problem example which if solved, should help me on the grander scale.  

Like before, I'm using iff statement to identify major and minor triads.  The problem is that only the minor a-c-e and a-e-c are identified.  I've also included a version using only integer numbers, but the problem is the same.  

On May 30, 2008, at 9:38 AM, v1025kernel wrote:

> *Also, what exactly is the 'right-to-left' issue?

Max patchers are evaluated starting at the right side of your patcher, 

and working across to the left. If two things are in exactly the same 

horizontal position, the lower object gets evaluated first.

That said, I think your problem is your use of pack. Like most Max 

objects, pack only outputs anything when something comes in its left- 

most inlet. You might be better served by pak, which fires when any 

inlet changes. Note that the arguments to pak are different from the 

Max patchers are evaluated starting at the right side of your patcher,  
and working across to the left. If two things are in exactly the same  
horizontal position, the lower object gets evaluated first.

That said, I think your problem is your use of pack. Like most Max  
objects, pack only outputs anything when something comes in its left- 
most inlet. You might be better served by pak, which fires when any  
inlet changes. Note that the arguments to pak are different from the  
arguments to pack.

Chris Muir
cbm@well.com	
http://www.xfade.com

> thanks for the help. it worked well with the example. How ever, in

> the patch that I've written, using more than on pack --> iff

> Can someone tell me why the A MAJOR section isn't working? I did the

> same thing I had done with the A MINOR section ... so it should work.

There is no need to test for all possible iterations if you sort then 

if ($i1==3 && $i2==6 && $i3==7) then bang

v1025kernel schrieb:
> thanks for the help.  it worked well with the example. How ever, in
> the patch that I've written, using more than on pack --> iff
> statement isn't working.
>
> Can someone tell me why the A MAJOR section isn't working?  I did the
> same thing I had done with the A MINOR section ... so it should work.

There is no need to test for all possible iterations if you sort then 
this if should do it...

if ($i1==3 && $i2==6 && $i3==7) then bang
another solution would be

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


"if and only if" statement