jamesson

I have a couple of situations where I need to see if a condition was true _once before_ but is no longer true. If it was true I should restet the conditional, ie

if A was once true then B
If B then C
if C then not B

logic-and-time

If B then (listen for) C but (don't listen for) A

if A was once true then (listen for) B
If B then (listen for) C but (don't listen for) A
If not B then listen for A again.


I did misspeak about "time", but this is interesting and potentially useful. By time I meant order of operations, not a specific timeframe. So, to be specific, I draw some rectangles on lcd, then I look to see if the value of some integer input falls within those rectangles (ie x is between a and b, y is between c and d).I need to detect this in sequence, ie if something falls within rectangle a, I will see if it falls within b. However, if it never fell into rectangle a I don't care if it falls into rectangle b. Furthermore, as long as I am in b I do not want to test for a.

I did misspeak about "time", but this is interesting and potentially useful. By time I meant order of operations, not a specific timeframe. So, to be specific, I draw some rectangles on lcd, then I look to see if the value of some integer input falls within those rectangles (ie x is between a and b, y is between c and d).I  need to detect this in sequence, ie if something falls within rectangle a, I will see if it falls within b. However, if it never fell into rectangle a I don't care if it falls into rectangle b. Furthermore, as long as I am in b I do not want to test for a.


This really sounds like a gate / switch / router problem. A-becoming-true opens a gate that passes to the listener for condition B. B-becoming-true opens the gate that passes to C. Use onebang along the way to handle your switching mechanism.

However, this is not a good way to do it, since it's a hard-wired solution and only really useful if you always know the number of rectangles in advance. However, you could do it via vexpr.

1. Do you _have_ to do it in sequence, (as in are you going to be dealing with lots and lots of rectangles such that executing this in sequence is absolutely necessary for efficiency purposes) or can you do all the calculations at once and then sort it out from there?

2. Are these rectangles concentric/overlapping?

3. Can you provide a usecase? (i.e. a worked out patch with what values you intend to input)

Here's a parallel (rather than sequential) way of approaching it:

This really sounds like a gate / switch / router problem.  A-becoming-true opens a gate that passes to the listener for condition B.  B-becoming-true opens the gate that passes to C.  Use onebang along the way to handle your switching mechanism.

However, this is not a good way to do it, since it's a hard-wired solution and only really useful if you always know the number of rectangles in advance.  However, you could do it via vexpr.

Some questions:
1. Do you _have_ to do it in sequence, (as in are you going to be dealing with lots and lots of rectangles such that executing this in sequence is absolutely necessary for efficiency purposes) or can you do all the calculations at once and then sort it out from there?  

3. Can you provide a usecase?  (i.e. a worked out patch with what values you intend to input)

Here's a parallel (rather than sequential) way of approaching it:


Many thanks for the active interest. Let me go eat and then I will post my patch.

Here is my patch, hope it's not too convoluted for you

a) I'm not entirely clear on what you mean by "at once".

b) As it stands the rectangles overlap. I can "fix" this, but it will be very time-consuming

It may be on the convoluted side. Much of the code on the right isn't doing anything because the messages are just going in the right inlet. In my experience, when my patches look like this, it usually means I'm not approaching it the way I need to, and that there is a more elegant solution. What I mean by elegant is this: it works as well for 1 rectangle as it does for 100. If you have to add more objects to handle more data, there's usually a better solution.

My question about "at once" is this: do you have to actually evaluate the logic in the order you specified, or can you test all the possibilities at once and then figure out from there where the chain broke? I went with the second approach via vexpr and it works much more simply.

Solving it in sequence is not a problem in traditional programming languages (and given what you're trying to do, you really should look at javascript, or if you don't have to have your window in your patch, java is excellent for this), but it's a bit more of a pain in Max. (Yes, you can totally do it, and if your criteria grew sufficiently large, it might make sense)

You have to keep track of a lot more things (am I on A/B/C/D?) which usually means counter, keeping track of states, etc. If you solve it with vexpr, it's scaleable AND stateless (unless you use the history portion I included, but that's pretty simple: it's just saying "if this is true now, or has ever been true...")

I think I'm also unclear as to what you're trying to do exactly. Is it hit detection within regions? This may do what you're looking for, but this is really a place where a procedural language is much better suited.

It may be on the convoluted side.  Much of the code on the right isn't doing anything because the messages are just going in the right inlet.  In my experience, when my patches look like this, it usually means I'm not approaching it the way I need to, and that there is a more elegant solution.  What I mean by elegant is this: it works as well for 1 rectangle as it does for 100.  If you have to add more objects to handle more data, there's usually a better solution.

My question about "at once" is this: do you have to actually evaluate the logic in the order you specified, or can you test all the possibilities at once and then figure out from there where the chain broke?  I went with the second approach via vexpr and it works much more simply.   

Solving it in sequence is not a problem in traditional programming languages (and given what you're trying to do, you really should look at javascript, or if you don't have to have your window in your patch, java is excellent for this), but it's a bit more of a pain in Max.  (Yes, you can totally do it, and if your criteria grew sufficiently large, it might make sense)  

You have to keep track of a lot more things (am I on A/B/C/D?) which usually means counter, keeping track of states, etc.  If you solve it with vexpr, it's scaleable AND stateless (unless you use the history portion I included, but that's pretty simple: it's just saying "if this is true now, or has ever been true...")

I think I'm also unclear as to what you're trying to do exactly.  Is it hit detection within regions?  This may do what you're looking for, but this is really a place where a procedural language is much better suited.


Sorry to belate getting back to you, I was a bit under the weather last night.

Hit detection with regions is exactly it, but I need to have a governing logic that maintains a certain order. Hopefully the attached images are sufficiently clear. X is in all cases the area value output by [dial]

Your suggestion re JS is excellent, I don't know why I didn't think of it before. I will pursue it in a couple of hours.

Your suggestion re JS is excellent, I don't know why I didn't think of it before.  I will pursue it in a couple of hours.

logic and time