Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: > So as I was saying, the 'next possible state transition' boxes seemt to > lag behind the current state. By placing an extra [del 10] inlet to send > each choice twice, this upates the next possible states correctly.
Just a note: What actually should be changed with my patch is the order, in which messages are triggered and their number. For this you should use [trigger] or [t ...] , and not [delay]. [del] may have a similar result in this case, but [del] should be used for timing things, not for ordering things. > However, it requires an initial message of '0' to [t b a] to initialize > the rest of the state machine to the proper location on the list. Then, > each subsequent choice can be made from the radio toggle. > > This becomes problematic because I would like to use the next possible > state transitions to display the voting choices. However, using the > workaround of [del 10] to send the choice twice means that the display for > the next possible state transition is actually changing twice (albiet very > quickly). I can imagine another hack-ish workaround involving a toggle to > allow or prevent the message being passed from the next possible state > transition(s) to the display, but I'd rather not have to do that if it's > not necessary. Yep, the real solution should be a different triggering. The left part of the patch now does the choice by looking up an element in a list of choices by position. The choice is send to the right part, which looks up a new pair of possible choices and sends it back to the left part, using [list]'s cold inlet to just store the choice. Displaying the choices also is done in the right part of the patch. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__
state-machine-reworked.pd
Description: application/puredata
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
