kcoul

Although of course Max isn't really intended for this purpose, I am finding it great for modeling logic circuits for my ComSci class, at least at first until I ran into this kind of issue while trying to model a digital clock circuit:

When chaining multiple gates together, there seems to be some kind of logical jitter that results in errant truths escaping the circuit where they shouldn't. I know it probably has to do with one evaluation executing slightly before another evaluation that would prevent the former from returning true. I'd appreciate help in pinpointing what I did wrong, the file is below. I stopped at troubleshooting the subpatcher for "0" once I found out I was getting the same superfluous truths from expr as I was from my own circuit chaining NORs and ANDs together, because it threw into question my above theory.

It's strange how the cascading toggles function properly, despite the fact that the captures show many more 1's escaping than the toggles reveal (because they are being 0'ed so quickly it's not noticable, I gather.

issue-with-logic-circuit-in-max

Oops, here are the pictctrl files to include in Max Search path to render the LED segments.

I should probably also mention that toggling the toggles manually in the blackbox subpatcher produces the intended LED sequence.

Hi again, never mind, I sorted it out, but it wasn't as elegant a solution as I was hoping for.

It turns out it has something to do with how I was using trigger messages in the basic building blocks I'd made, so that it would evaluate no matter which input changed (which on its own, would be more ideal than only evaluating if the leftmost input changed, but in this case presented an interesting bug).

The workaround was to use expr objects for the even numbers so that the input that went high would be mapped to the hot input.

If anyone is interested and can find a solution that combines the best of both worlds, I'm really interested in knowing. Until then, here is the correct patch:

It turns out it has something to do with how I was using trigger messages in the basic building blocks I'd made, so that it would evaluate no matter which input changed (which on its own, would be more ideal than only evaluating if the leftmost input changed, but in this case presented an interesting bug). 

The workaround was to use expr objects for the even numbers so that the input that went high would be mapped to the hot input. 

If anyone is interested and can find a solution that combines the best of both worlds, I'm really interested in knowing. Until then, here is the correct patch:


Issue with Logic Circuit in Max