Compatibility guide

Browser compatibility for Gesture Synth

Gesture Synth needs three browser capabilities at the same time: camera access, client-side hand tracking, and Web Audio. This guide explains what to check before you troubleshoot the gestures themselves.

What your browser needs

The play experience relies on the MediaDevices API to request a webcam, MediaPipe Tasks Vision to detect hand landmarks in the browser, and the Web Audio API to generate sound. A browser can load the marketing pages without all three capabilities, but the instrument cannot work normally unless camera and audio features are available together.

Use a current desktop browser rather than an old embedded webview. Chrome and Chromium-based browsers are the most predictable baseline for webcam permission and Web Audio behavior. Other modern browsers may work, but privacy settings, camera selection, autoplay rules, and hardware acceleration can change the result. If a browser is several versions behind, update it before diagnosing Gesture Synth itself.

A quick compatibility checklist

  • The page is loaded over HTTPS, not an insecure HTTP copy.
  • The browser can see at least one connected webcam.
  • Camera permission is allowed for gesturesynth.org.
  • Browser audio is not muted and the active output device is available.
  • JavaScript is enabled and content blockers are not breaking MediaPipe resources.
  • The device has enough CPU/GPU headroom for camera decoding and hand-landmark inference.

If all six are true, open the play page and test one simple chord before changing keys, synth tone, or expressive controls.

Camera permission is separate from camera quality

A permission prompt only answers whether the browser may access a camera. It does not guarantee that the selected camera has a useful angle, frame rate, or exposure. If permission is granted but hands are not recognized reliably, first check framing and light. Put both wrists and fingertips inside the frame, move slightly farther back, and avoid a bright window directly behind your hands.

If permission was denied, use the lock or camera control near the browser address bar to change the site permission, select the intended webcam if the browser offers a device choice, and reload the page. Gesture Synth intentionally requests video without microphone access, so a missing microphone permission is not an error.

Audio can fail even when tracking works

Browsers protect users from unexpected sound, so the instrument starts audio after an explicit user action. If the hand overlay works but you hear nothing, confirm the tab is not muted, system output is routed to the device you expect, and both hands are producing a valid degree and chord-quality combination. A closed right-hand fist is intentionally silent.

Bluetooth audio can add noticeable output latency even when camera tracking is healthy. For the clearest timing test, compare built-in speakers or wired headphones with the same gesture. That helps separate audio transport delay from hand-tracking delay.

Performance and laptop power settings

Hand tracking runs continuously while the camera is active. A device under heavy CPU load may process fewer frames or make gesture changes feel less stable. Close unnecessary video calls, games, or other camera-heavy tabs before testing. On laptops, aggressive low-power modes can also reduce processing performance.

If tracking is smooth at first and degrades later, check whether the laptop is thermal-throttling, whether another app has begun using the camera, or whether a browser extension is injecting work into the page. Try a private window with extensions disabled as a diagnostic comparison, not as a permanent requirement.

Browser differences worth checking

Browsers can expose the same camera and audio APIs with different permission UI and privacy defaults. One browser may remember a previous camera denial while another asks again, and an extension can affect only one browser profile. That is why switching browsers is useful as a diagnostic comparison even when you intend to return to your preferred browser afterward.

Do not treat a successful test in another browser as proof that Gesture Synth requires that browser. Instead, compare the differences: camera permission state, selected input device, tab mute state, content blockers, hardware acceleration, and whether the model resources load successfully. The comparison narrows the cause without turning compatibility advice into an unsupported list of guaranteed browser versions.

When an extension or privacy tool is involved

Script blockers, strict network filters, and privacy extensions can block third-party runtime or model files even though the main Gesture Synth page loads normally. If the page starts but hand tracking never becomes ready, test a private profile with extensions disabled and compare the network behavior. If that fixes the issue, re-enable tools one by one and allow only the resources required for the instrument rather than disabling protection globally.

What to test next

Once the browser, camera, and audio path are confirmed, move to gesture-specific diagnosis. Thehand-tracking troubleshooting guide covers disappearing hands, flickering finger counts, overlapping hands, and unstable chord changes. The webcam privacy guide explains which camera data stays in the browser.