Finite State Machine – Is It an Appropriate Solution?

I am sure you already know this but just in case:

1. Make sure every node in the state diagram has an outgoing arc for EVERY legal kind of input (or divide the inputs into classes, with one outbound arc for each class of input).

   Every example I have seen of a state machine uses only one outbound arc for ANY erroneous input.

   If there is no definite answer as to what an input will do every time, it is either an error condition, or there is another input that is missing (that should consistently result an arc for the inputs going to a new node).

   If a node doesn't have an arc for one type of input, then that is an assumption the input will never occur in real life (this is a potential error condition that would not be handled by the state machine).

2. Make sure the state machine can only take or follow only ONE arc in response to the input received (not more than one arc).

   If there are different kinds of error scenarios, or kinds of inputs that cannot be identified at state machine design time, the error scenarios and unknown inputs should arc to a state with a completely separate path separate from the "normal arcs".

   I.E. if an error or unknown is received in any "known" state, then the arcs followed as a result of the error-handling/unknown input should Not go back into any states the machine would be in if it only received known inputs.

3. Once you reach a terminal (end) state you shouldn't be able to return to a non-terminal only to the one starting (initial) state.

4. For one state machine there should not be more than one starting or initial state (based on the examples I've seen).

5. Based on what I have seen one state machine can only represent the state of one problem or scenario.
   There should never be multiple possible states at one time in one state diagram.
   If I see the potential for multiple concurrent states this tells me I need to split the state diagram up into 2 or more separate state machines that have the potential each state to be independently modified.

Probably the best way to implement FSMs in OOP languages is sticking to the State Design Pattern

That pattern provides a general structure to design and implement FSMs, dividing the FSM in two "sides": The context and the state, being the state a hierarchy of all the different states the context can have (a context can only have a very limited amount of states at a single time, usually only one). Then, the state transitions are modeled, usually either in the client (the class that uses the context will decide when to explicitly transition to a new state, making the context instance behave differently), or in the states (when each state is responsible of checking the transition conditions and perform the actual transition). The first approach has the advantage of a lower cohesion between states, making them reusable in implementations of other FSMs, but with a much more complex client class. The second approach has the opposite side effects.

In your case, I'd model System with the role of Context, State with the role of State, and Menu (and its submenus) as different ConcreteStates. If StepSequencer and SamplePad are to be exclusive of a single menu/submenu, they'd be attributes of that individual state. Otherwise, (i.e., shared or persistent between menus), as attributes of System. That decision will depend on your actual needs.

Now, about your design (and this is a little off-topic), StepSequencer and SamplePad don't look like actual states (neither by their uses nor by their names). Personally, I'd bet it's that way just because their interface is apparently identical to that of states (def buttonPress(self, numberButton):). If that's the reason, and you did it that way to avoid duplicating code, don't. It's okay to have code duplicated in certain occasions (e.g., when the base interface is likely to change in different directions over time, as stated by Robert C. Martin in his book Clean Architecture). Keep this in mind and consider deriving them from a different base class other than State.