One interesting feature is that there are several buttons that have different actions associated with short and long presses. So I can imagine per-button state machines that do something like:
UP --pressed--> DOWN --timeout--> LONG_DOWN <--released---- | <---------------------released--------+
These could feed events like left_button_short_press, right_button_long_release etc into a main state machine.
Can you outline how you would implement this in MSM?
I implemented it exactly as you described.
I can see how you could store the button identifier as event state and send e.g. short_press(left_button) to the main state machine, but this would then need transition rules using guards to test the button id. (I don't think this is an application for a sub state machine because each button's machine runs concurrently, right?)
To make the follwowing answer clear, I just added in the sandbox (msm/libs/msm/doc) a BoostCon09 subdirectory. You will find the diagrams (top fsm, menu and playing submachines) and an implementation using a standard front-end and for the fun, another one using eUML (tested with VC9 and g++-4.3). I didn't generalize like you suggested. Though I like your solution and it is probably going to work, I didn't want to make the example more complicated (it is already complicated enough). To solve the concurrency problems, I simply added more regions and each button is handled in one of them. It is not such a big repetition because the south button has its own handling anyway. The interesting and complex part is not so much the button handling, which could be done with an ad-hoc solution too, but the separation of tasks between the regions. One handles the hold button and stops all processing using an interrupt state, some handle the buttons, and others are simply here to give to an hardware event (like using the middle button) a different meaning according to the state where the state machine is. For example, CheckMiddleButton is doing just this. Only one state. All regions are small, and each handles a very specific part of the problem. See it as a sort of "divide and conquer" ;-) The whole point of the example was to show how, using UML techniques supported by MSM, writing a mock-up for an iPod was easier than using an ad-hoc solution. We spent 90mn purely on diagram and used a tool to generate the code instantly. And this was the second point, to show how MSM was supporting a model-based approach and that such a tool was feasible. Christophe