The Actor Framework might not be the right choice for you, but I don't think you should rule it out completely. I think it can be a very good architecture choice for many applications. I'm not sure if you're familiar with how it works, but the basic idea is that each "actor" you create is an object which inherits from the Actor object provided in the framework. Actors are asyncronously running processes, and the framework already has built in ways to launch actors and send messages from one actor to another. Really all you do when you create an actor is write the code that it should run in response to specific messages, which can involve sending more messages to other actors or itself.
I often make state machine actors by putting a state enum in the actor's private data and then having that actor send itself a message periodically and whenever it receives that message it checks its state and potentially sends other messages/does things it needs to.
I think what would point you towards using the Actor Framework would be if any of those slave state machines 1, 2, ... n will be the same as each other, because one of the biggest benefits of the Actor Framework is that you can launch multiple instances of a single actor you've written.
--Hope
