AV Institute · Week 2Programming & Control Basics

Lesson

Variables, Logic, Conditions, Events, States & Feedback

Est. 70 minCompetency: Model room behavior with variables, states, and event-driven logic.

Learning objectives

Use variables to represent room state (power, source, volume).
Apply conditions and logic to drive sequences.
Model the room as a finite set of states.
Write event-driven logic that updates the UI from real feedback.

Vocabulary

Variable: A named value that holds room state (e.g. currentSource, isPowered).
Event: Something that happens — a button press or incoming feedback — that triggers logic.
Condition: A test (if/else) that branches logic based on state.
State machine: A model where the room is in one state at a time and events cause transitions.
Feedback: Status a device reports back, used to update variables and the UI.
Pulse vs latch: A momentary trigger vs a held boolean state.

Lesson content

Programming an AV room is mostly tracking state and reacting to events. A handful of variables — is the display on, what source is selected, how loud — plus conditions on those variables, describe almost every behavior.

The core variables for a room

displayPower   = OFF          // bool
currentSource  = NONE         // laptop | codec | none
volume         = 50           // 0..100
mute           = true         // bool
roomState      = STANDBY      // standby | starting | on | shutting_down

Events drive logic

Logic is event-driven: a button press or an incoming feedback string fires a handler. The handler reads state, runs a condition, sends commands, and updates variables and the UI.

event: button "Power" pressed
  if displayPower == OFF:
      send display "PON"        // power on
      displayPower = PENDING_ON
  else:
      send display "POF"        // power off
      displayPower = PENDING_OFF

State machines keep it sane

Model the room as states: STANDBY → STARTING → ON → SHUTTING_DOWN → STANDBY. Each event only does the right thing for the current state. This prevents 'press power twice and the room gets confused' bugs.

Feedback closes the loop

1Send a command and set a 'pending' state.
2When the device reports back, compare to what you expected.
3If it matches, confirm the state and update the UI.
4If it does not (or times out), retry or show an error.

Defensive programming

Never assume a command succeeded. Always confirm from feedback and handle the case where it did not. That single habit removes most 'the panel says on but it's off' complaints.

Worked example

Volume: a slider event sets the volume variable and sends a level command to the DSP; the DSP echoes the level back, and the UI updates the slider to the real value. Mute: a button toggles the mute variable and sends mute on/off; the DSP confirms and the button reflects true state.

Implementation checklist

✓Track power, source, volume, mute, and room state as variables.
✓Make logic event-driven, not polling where possible.
✓Use a state machine to keep sequences sane.
✓Confirm every command from real feedback before updating the UI.
✓Handle non-response with retry or error states.

Downloadable study guide

study-guide.txtcopy-paste ready

01. Core variables: displayPower, currentSource, volume, mute, roomState.
02. Logic is event-driven: button or feedback fires a handler.
03. State machine: STANDBY → STARTING → ON → SHUTTING_DOWN.
04. Confirm commands from feedback; never assume success.