169 bug udp socket bottleneck osc messages not all being recognized

[janikwitzig]

Closes #169

This PR addresses an issue where the variable preloading on startup would fail for some variables. The likeliest cause of this is overload of the console or the companion host.

The problems are twofold:

• requesting too many variables at once causes osc messages to be lost
• the variable updates take too long

The first issue is addressed by loading variables in chunks instead of all at once. The chunk size and delay between chunks are configurable in the advanced options.

The second issue is solved by re-structuring the variable updates. Instead of iterating over all received messages and individually updating every single variable, the changes are collected and updated in one go.

Furhtermore:
Instead of manually defining all variables to load, the WingState now uses a getter function of the VariableHandler to retrieve all variable paths, reducing code size and maintainability.

[janikwitzig]

I am investigating this further and have found some insight. Generally, the behavior is that feedbacks might or might not work after the connection starts up. If they do work, it is a matter of time until they don't. After that, it is also possible that they start working again.

• the logger is not good for performance. it probably needs to go, but with it also some convenience features such as logging every message
• removing the osc forwarder seems to increase performance, could also be a misconfiguration on my end
• I am not fully in the clear whether the console version is not to blame. Looking at the incoming packages with wireshark also reveals some pauses in traffic. If this truly is the case, there is nothing that we can do
  • has the connection configuration changed from v2.2.0?

[janikwitzig]

I was able to optimize some code in the variable handler. It appears to work. I‘ll start re-enabling features and push

[Copilot]

Pull request overview

This pull request addresses a UDP socket bottleneck issue (#169) where OSC messages were being lost during variable preloading on startup, causing some variables to fail to load. The solution involves chunking variable requests and batching variable updates for better performance.

Changes:

• Implemented chunked variable loading on startup with configurable chunk size and delay to prevent UDP socket overload
• Refactored variable updates to collect and batch changes instead of processing them individually, improving performance
• Centralized variable path definitions by adding a path property to variable definitions and using getAllVariables() getter

Reviewed changes

Copilot reviewed 25 out of 25 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
src/variables/*.ts	Added path property to variable definitions for automatic OSC path retrieval
src/variables/index.ts	Added getAllVariables() function and VariableDefinition interface with optional path property
src/handlers/variable-handler.ts	Refactored to batch variable updates and use debouncing; changed update methods to return arrays
src/state/state.ts	Implemented chunked variable loading with configurable parameters
src/index.ts	Added message batching with debouncing and refactored start/stop lifecycle
src/handlers/*.ts	Updated to accept Set<OscMessage> instead of individual messages for batch processing
src/config.ts	Added configuration options for chunk size and delay between chunks

Comments suppressed due to low confidence (3)

src/variables/bus.ts:65

• The bus variables don't have the path property added, unlike all other variable files (channel, auxiliary, main, matrix, dca, mutegroup, gpio, wlive, talkback). This means bus variables won't be prefetched on startup when the requestAllVariables function is called. This appears to be an oversight and could result in bus variable values not being loaded during startup.

		variables.push({
			variableId: `bus${bus}_name`,
			name: `Bus ${bus} Name`,
		})
		variables.push({
			variableId: `bus${bus}_mute`,
			name: `Bus ${bus} Mute`,
		})
		variables.push({
			variableId: `bus${bus}_level`,
			name: `Bus ${bus} Level`,
		})
		variables.push({
			variableId: `bus${bus}_pan`,
			name: `Bus ${bus} Pan`,
		})
		for (let main = 1; main <= model.mains; main++) {
			variables.push({
				variableId: `bus${bus}_main${main}_mute`,
				name: `Bus ${bus} to Main ${main} Mute`,
			})
			variables.push({
				variableId: `bus${bus}_main${main}_level`,
				name: `Bus ${bus} to Main ${main} Level`,
			})
		}
		for (let send = 1; send <= model.busses; send++) {
			if (bus == send) {
				continue
			}
			variables.push({
				variableId: `bus${bus}_bus${send}_mute`,
				name: `Bus ${bus} to Bus ${send} Mute`,
			})
			variables.push({
				variableId: `bus${bus}_bus${send}_level`,
				name: `Bus ${bus} to Bus ${send} Level`,
			})
			variables.push({
				variableId: `bus${bus}_bus${send}_pan`,
				name: `Bus ${bus} to Bus ${send} Pan`,
			})
		}
		for (let mtx = 1; mtx <= model.matrices; mtx++) {
			variables.push({
				variableId: `bus${bus}_mtx${mtx}_mute`,
				name: `Bus ${bus} to Matrix ${mtx} Mute`,
			})
			variables.push({
				variableId: `bus${bus}_mtx${mtx}_level`,
				name: `Bus ${bus} to Matrix ${mtx} Level`,
			})
		}

		variables.push({
			variableId: `bus${bus}_color`,
			name: `Bus ${bus} Color`,
		})

src/handlers/variable-handler.ts:410

• The variable names for elapsed time have been changed from session_len to elapsed_time (lines 382-387), but the sessionlen command still uses the old session_len variable names (lines 404-409). This creates an inconsistency where etime updates elapsed_time variables but sessionlen updates session_len variables. Either both should use the same naming convention, or they represent different data and this is intentional - in which case it needs clarification.
  src/handlers/variable-handler.ts:97
• The old implementation rounded all numeric values before setting them (lines 240-241 in old code), ensuring that values like 1.2345 became 1.2 for decimal values or 1 for integers. The new implementation doesn't apply this rounding consistently across all variable types - only specific update methods apply rounding (gain, fader, pan). This could result in variables having more decimal places than expected, potentially breaking existing integrations that rely on the previous rounding behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.