Don't have time to review the code but the answer to this sort of problem is almost always "make a class, then put the variables on the class".  When it gets big enough, figure out how to separate it into separate classes with different responsibilities,but it sounds like that won't be your problem for a while.

Also read-only global variables are called constants and are perfectly fine, so if you want to just hardcode some configuration into the program, sure.  Just comment them so you know what they change, and don't do it if you think they're going to come from a file later--or at least, not without some thought.

Also, a trick I've used when dealing with GPS coordinates, save a spoken position. Initialise it to None:

class StickClass:
    spoken_option: Optional[float] = None

    def stick_thing(self, position: float) -> None:
        if self.spoken_position is None or (max(position, self.spoken_position) - min(position, self.spoken_position)) > 0.2:
            self.spoken_position = position
            speak(f'New position is {position}.')

That makes sure the position has to change by 0.2 before it'll speak the difference.

Particularly useful when you've got some really sensitive data like GPS or your stick position, to not get spammed. Play with the value until you're happy.

I'm not saying I'm not gonna do it, In fact, I will. I am just grumbling about it because I hate classes. The second you start using them, then everything becomes a class and you've got objects all over the place because you need one for this and that and the other.

global mutable state sure is something you want to avoid, since it can be accessed anywhere, making it difficult to reason about. one way to limit the scope definitely is what has been proposed, to use a class and make the mutable state a field of the class. that way only the methods should be the ones mutating that state, but I would actually agree with OP that OOP often leads to over engineered code and can actually get really messy. not saying OOP is totally bad, but it is also entirely unnecessary. yes it is necessary to use classes in python to create convenient packages of various variables grouped together, however it is not necessary to do the Oop thing of mixing data and logic by giving those classes methods that are responsible for operating on the fields of the class.

I can propose a simple procedural style, data-oriented

design where data and logic are seprated, which imo is simpler and cleaner.

Again, not saying this is the good way to do it and the Oop way is the bad way. The OOP way is fine too, but just want to provide an alternative, as this thread is giving the impression that it is the only way.

So how else can we limit scope of mutable state? Well simplest way is instead of global variables to have local variables, either in a loop or a function. Let’s say I have a main function that gets called when the program starts up. You can just initialize all your state as local variables and when you need some function to have access to it, you just explicitly pass it as a argument to that function. That function can then read that state you pass it and if it is mutable  then it can also change it. Small example below:

def main():
  state = True # in this case state is just a boolean
  while True:
    foo(state) # foo will be able to read state
    # since booleans like all primitives are immutable, in order for a function to change it
    # it will have to return a new value and the caller will have to update the state
    new_state = bar(state)
    state = new_state
  # end while
#end def

If you want to package related data together so it is more convenient to pass around and also gives you a mutable container then the simplest and most efficient is to use pythons relatively new dataclasses.

from dataclasses import dataclass

@dataclass
class InventoryItem:
    """Class for keeping track of an item in inventory."""
    name: str
    unit_price: float
    quantity_on_hand: int = 0

this neat decorator will auto generate an __init__ and __repr__ function, so you can use it simply like this:
item = InventoryItem("chocolate",  2.5)
item.unit_price #access a field
item.quantity_on_hand  = 50 # mutate the state

since the dataclass acts as a mutable container, you don't have to do as was done in my previous example of having the function return a new state and the caller being responsible for updating it. although that way has major advantages in being able to reason about the code and making your functions testable. instead when passing a dataclass, the function can mutate it directly:

def sell_item(item: InventoryItem):
  item.quantity_on_hand -= 1 # change is reflected everywhere

@8
I entirely fail to see how what you are proposing is helpful for a new programmer.  There is a reason people don't start with functional programming.  You tend to provide entirely correct answers without considering your audience, which is something you should probably work on.

Also, your approach is almost exactly equivalent to classes anyway, at least in Python.  Except that you've added several layers of obfuscation and basically said "implement what classes do manually".

I'm not saying you're wrong necessarily, just that you really have to consider who you're talking to.  "Have you considered not using classes and adopting functional programming, only to end up back where you started except using a bunch of things you probably weren't ready for?" is essentially what you're saying right now.  OP isn't ready to finish going down the road of functional programming and probably doesn't have the experience to do so without ending up with spaghetti code.  While it is reasonable to say that maybe we could teach more functional programming at the beginning or something, that isn't the world we live in at the moment.

@9
It's probably fine enough for now, it's just something you should be aware of.  Also, attrs may deal with it, and it may not even be a problem depending on what benchmarks say.

@10 although I do often advocate functional programming, this instance I am not actually advocating FP. the alternative solution I am proposing is just regular procedural imperativ programming.

and I think in this case I am considering the audience, since my proposal is simpler than jumping to doing OOP, since it doesn't require OP to adopt any new paradigm and to start thinking of how to organize their code in classes. The OP specifically complained about needing to learn OOP in order to solve this problem and so I am providing a way that doesn’t require any OOP sort of design, but instead just use local variables as a way to not need to deal with global mutable state. I’ll just re-iterate I don’t have a problem with OOP, but in this case it is much more doing OOP for OOP sake and the problem can be tackled more simply in a strictly procedural non-OOP way.

@13
That feels like extra typing, and you don't get much that using a module doesn't already give you.

Why not instantiate the classes somewhere? A nice little application.py module should do it, then you can keep all your instantiated whatnots in there. That way, if for some reason (multiple controllers in your case maybe?) you can simply create a new instance.

If your program is too small to deserve not using globals, if you are going to finish this then never touch it again, then just use globals.  Doing class-level variables that get changed by classmethods doesn't help you because they're globals, you've just put a little bit of code on them so that you can pretend they're not and feel good about it.

I suspect what you want is a singleton.  To do that, make a class like you're going to make an instance, then make an instance of that class and use it as the global.  It's not as good as not having globals, but it's better than making everything a global.

There is a difference between a script and a program.  A script does one thing and is effectively write only.  You are talking about this like it's a script.  Scripts don't deserve being clean code.  You finish them, they're small, they're done forever, it doesn't matter.  If that's the case, wait for a bigger project in which to learn about modularity and avoidance of globals.

@17 it is starting to seem to me that the issue you are running into is more a matter of having your state be in scope in the function that handles the event loop and to update it between iterations of the loop. I cant access your code, but if you could show how the event queue code is structured then that would allow to give better advice

@19
I tell you what, that is some nicely laid out code!! We always moan when code is badly formatted, or not formatted at all, but that is lovely to read. Well done.

your code looks quite clean. for keeping track of state between iterations of the main loop, I think just setting up state inside main() before the main loop starts should be fine. then you can update the state inside the main loop and it will track it between the different iterations of the loop. when a subprocedure needs access to it you can pass it in as an argument like you are doing for buzz(). and if a subprocedure like buzz needs to be able to update the state then it can return a new one that will be updated in the main loop, something like:
state = buzz(state)

the thing this earns you over using global variables is that if you suspect there is some bug with how state is being updated, you know you just need to look inside the main loop code, since that is the only place that has access to changing it, whereas with a global variable you'd need to scan all the code.