MixControlServer

Remarks

Loopback only, and not configurable. It binds to Loopback and nothing else: a listener on a game's process that answers the network is a way into that process, and the fact that all it can do is move a fader is not an argument anybody should have to make. An editor on another machine — a devkit session — tunnels, which is one line of ssh and puts the authentication somewhere that has some.

Off unless something starts it. Nothing here runs in a build that did not ask, and a shipping build should not ask. There is no authentication because there is nothing to authenticate against on a loopback socket, which is exactly why it must stay on one.

Writes are queued and applied on the game thread. The mixer's whole threading model is one writer and one reader; a socket thread writing bus gains would be a third party to an arrangement that has room for two. So a set is parsed on the socket thread and performed in Update, which is where every other change to the mix happens.

Reads come from a snapshot. Walking the bus list from another thread while the game thread adds to it is the other half of the same problem, so Update leaves a copy behind and the socket thread answers from that. It is a few frames stale, which for something a human is looking at is no staleness at all.

The protocol is lines of text, because the client is a tool and a human debugging it with nc is a feature: list, get <path>, set <path> <value>, bye.

Fields and properties (6)

• public int RefreshHz

  How often the snapshot a client reads is brought up to date.

• public int Port

  Which port it is listening on, or zero if it is not.

• public IPEndPoint? EndPoint

  Exactly where it is bound, which is always a loopback address.

• public bool IsRunning

  Whether it is listening.

• public bool IsConnected

  Whether a client is connected.

• public long AppliedChanges

  How many changes have been applied since it started.

Methods (5)

• public MixControlServer(MixControl control)

  The wire an editor drives a running game's mix down.

• public void Start(int port = 0)

  Starts listening on the loopback interface.

• public void Stop()

  Stops listening and drops any client.

• public void Update()

  Applies what a client asked for, and refreshes what it can read. Once a frame.

• public void Dispose()

  Performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources.

Used by (1)

• MixControlServerTestsVixen.Audio.Tests