The patch below takes three values that have to meet a condition.
it is then packed in a list. What I am expecting is to get the value 111 to test true. What happens looking at the print results is that the value can be 110 and for some reason the equal to condition function will say true!?
No sure whats going on there is the logic working differently from programmes such as c or python?
Many thanks
-
PD Logic conditions
-
Still surprising that [1( send to [== 111] would result to 1.
-
Ah ok, i think it is because the list gets distributed to all the inlets, so the [==] will check 1 against 1.
-
Yes you're right, sending [0 0 1( as he did in the second post, the list gets truncated to [0 0( and distributed to the two inlets. I'm going to edit my earlier post which was wrong.
-
@weightless Yes, i tried this and was super confused:
But at the time the [1( on the right reaches the [==], the creation argument is already overwritten by the second 1 of the list. -
you mean the [1( on the left, I imagine? Because the third 1 of the list gets truncated.
This shows clearly what happens!
-
what happens for example if you want to count or use the binary using the logic in pd?
with just four buttons you can make 16 gestures. Does pd not lend itself to this ? would is be a time to use pack ? -
@Fauveboy i guess usually you would just use [list-drip] from list-abs to iterate over all the elements of a list and build your counting or other logic around that.
Here is another awkward example of the use of [list tosymbol] that simulates some binary logic:
list-binary.pdBut this is very specific and most of the times you just got to build your own logic with the few basic objects we got.
-
@Fauveboy your original patch ought to work if you remove the spaces from the message box, ie. [$1$2$3( instead of [$1 $2 $3(. But if you try this, you will find an annoying error message coming from the [==] object. The reason is that the output from the message is being interpreted as a symbol, not a float. You can fix with [symbol2list] from the zexy library, like this:
However, this definitely isn't as efficient as the solutions that others have suggested.
-
no need to use the zexy [symbol2list] now. vanilla has [list tosymbol] and [list fromsymbol] now
-
More logic problems.....
using the patch you've shown me how can a button be toggled on once then left on until the button is pressed again?when the conditions are true ( this happens when a button on the grid interface Im using is pushed ), equal to 3 is true. But the problem is i have to hold the button down to keep the signal active...I was hoping using the button object would only send a bang when it receives a 1 but it sends a bang when it receives 0 too ?
-
ive tried using the sel 1 object but when I press one of the other buttons on the grid a bang for some reason still gets through?
-
@Fauveboy Putting [change] before [sel 1] could solve this.
Also with [change] you wouldn't need [sel] and bang anymore, i guess.
-
@ingox fraid not...the button toggles on but when any other one is pushed it swtiches off and vis versa
-
@Fauveboy Ah ok, i thought this would be the desired behavior. If you want it to toggle only once and never again after this you can use this switch:
Obviously you can open the spigot again if needed by sending 1 to the right inlet. -
I think i got you wrong. This might be what you are looking for: I changed the order of the receives so now the results of x and y will be stored in the expression object, but only s will trigger the hole thing.
-
@ingox said:
@Fauveboy Ah ok, i thought this would be the desired behavior. If you want it to toggle only once and never again after this you can use this switch:
Obviously you can open the spigot again if needed by sending 1 to the right inlet.thanks. this solved my problem in the experimental mouse plugin thread. interesting ideas.
-
Just to continue extending logic musings here.... numbers larger or equal to 12 still get through the gate which i imagine to be closed when equal to 15 is false?