You were not actively tuning in to the auditive channel of information, so the doorbell was processed unconsciously. It is a trigger for a procedure of answering the door. Is there a process that tracks all input signals, and has a mapping of signal -> procudure trigger? Of course not. The procedures themselves know which signals to expect. But that would be strange as well. It would require that all procedures are all active at the same time, waiting for the next signal to come along. In this interpretation, all processes are state machines, "active" at the same time. Active, but dormant. Waiting for some signal. This is not impossible. But who is doing the interpretation from "high pitched noise" to "doorbell ringing"? Is it the door answering process, or some other process? It is the semantic interpretation of a phonological stimulus. Can it be done unconsciously? Do you first need to pay attention to the sound, to hear it's a doorbell, or do you first know it's the doorbell and then you pay attention? I think you first need to pay attention. So the sound is calling your attention. Is it just because it's a high pitched sound? No that doesn't matter. Your attention would be drawn as well if you your name was spoken out by someone.

I think it is not possible that the door opening procedure performs the semantic interpretation, because the level of processing is different. The procure consists of some high-level social steps, very different from the low-level step of phonological interpretation.

If the procedure itself would do the interpretation, it would follow that hearing the bell could be interpreted very differently as well, by some other procedure. Myself, I think that this is not possible. Unconscious processes mapping phonological signals to meaning are not context dependent.

Once the procedure answer door is activated by the signal door bell ringing, it changes to a different state: walk to door. This doesn't happen automatically, of course, as we are not a dog. The procedure sends a request for walking to the door to the CPU, or starts shouting at the director from the audience. If the director grants the procedure access, the procedure will now be the active context.

The active context is performed by default, and does not need to beg for attention each time something happens. So once we're walking to the door, we have paused writing the letter. Since this procedure was not finished, it will keep asking for attention until it gets it. So when the door is answered, and that task is done, the process of writing the letter will continue.

I said that the door answering process is active all the time. That's all nice, but can you actually say that there is a single door answering process? You can answer several doors at the same time can't you? Or write two letters at the same time. And each of these processes is different, has its own state. Sure, you cannot drive two cars at the same time, but that's more a physical constraint. You could drive two cars in a computer game for instance. Yes, you would need to switch context, but still, you would be executing several processes based on the same template (or frame), at the same time.

Now there a several ways in which different processes can be created based on the same template. By means of instantiation, or prototyping. Which one to choose? I think it is important here that the instance of the process creates feedback to the template, so if you learn something about the process while doing it, this will immediately influence the way the other process based on the same template is performed. So the process instance that is instantiated has a link to the template process and can change the template at any time.

Is there a single process waiting for the door bell all the time or not? Is the template process reacting to the signal? That's not possible, because it is abstract. I think there are no processes active if there's no need. I think a process gets instantiated when a trigger in the process template is matched as part of LTM associative memory. Process templates are stored in LTM, and so are all triggers that cause state transitions.

If one of these triggers is matched associatively, a process instance is instantiated, in a certain state. So, say, a friend suddenly throws you a ball. You will recognize the trigger as being part of the throw-and-catch procedure. So this process is instantiated. It is not just activated, because several instances of the same task may be active at the same time. Some other dude may throw you another ball, and then you are playing the game twice at the same time. You can do this, even if you have never played it with two persons before.

If the procedure is instantiated, it is important that it be destroyed as well, or the number of active processes just increases. Processes have terminal states. Once a process reaches one of these, the process is destroyed. All that is left of it are traces in episodic memory.