Why does connecting time out in one browser but work in another?

Because on Windows only one program at a time can own a USB-MIDI port, and a browser claims every port on the machine as soon as any page asks for MIDI, then holds them for as long as its process lives. A second browser with GP200 Studio open — or Valeton's editor, or a DAW — takes the pedal away from the one you are looking at. It reads as "Response timeout" rather than "not found", because listing ports does not open them, so the GP-200 is found and simply never answers. Close the other browser completely (Chrome can outlive its last window: check the system tray and turn off "Continue running background apps" in chrome://settings/system), quit the official editor and any DAW, then replug the pedal. If nothing else is running, compare the #use-winrt-midi-api flag between the two browsers — that MIDI backend is known to hang on the System Exclusive messages this app uses — set the failing one to match, and relaunch it.

Which browsers work with the Valeton GP-200?

Chrome or Edge on any desktop OS, and Chrome on Android. Firefox and Safari do not implement Web MIDI, so they can edit and export files but cannot talk to the pedal.

Does it work on Linux?

Yes — anywhere Chrome or Edge runs, including Linux, which the official Valeton editor does not support at all.

Why can't Chrome see my GP-200 on Linux?

Two causes look identical from the browser, and in both the CONNECT message lists only "Midi Through Port-0". Either your browser is a Flatpak or Snap build, which gets /dev/snd but no /run/udev and so drops every USB device, or the ALSA sequencer bridge is not loaded. Fix the first with "flatpak override --user --filesystem=/run/udev:ro " and a full browser restart; fix the second with "sudo modprobe snd-seq-midi".

Why does my Flatpak or Snap browser not see any USB MIDI device?

Chromium binds ALSA cards to sequencer clients through udev, and a sandboxed browser is given the /dev/snd device nodes but not /run/udev. Every card-backed port is dropped and only card-less ones like Midi Through survive. Run "flatpak override --user --filesystem=/run/udev:ro com.brave.Browser" with your own app id, then quit the browser completely and reopen it — closing the window is not enough. A natively installed Chrome or Chromium needs none of this.

Connecting your GP-200

Click CONNECT on the landing screen or in the top bar (Chrome/Edge only). A short handshake reports your firmware; an unsupported firmware raises a compatibility warning. On connect, the unit's current preset loads into the editor automatically.

From then on, every edit (toggles, effect swaps, knob turns, reorders) streams to the device live, so the board is a real-time remote for the pedal. The top bar shows a connection dot, the current slot, firmware, and a SYNC counter while pushing. Changes you make on the hardware flow back into the editor too.

About the firmware warning

The preset format has only been verified against firmware 1.8. If your unit reports anything else you will get a compatibility dialog before you can edit, because the byte layout of a patch is exactly the kind of thing a firmware update moves , and writing a misread layout back to the pedal is how presets get corrupted. You can dismiss the warning and continue at your own risk; export a full ZIP backup from the patch manager first if you do.

If the pedal isn't found

Check the browser. Firefox and Safari do not implement Web MIDI at all, so there is nothing to fix there , use Chrome or Edge, on any of Windows, macOS, Linux, ChromeOS or Android.
Check the cable. A surprising number of USB cables sold with pedals are charge-only and carry no data lines.
Close the official editor. Most systems give one application exclusive access to a USB-MIDI port, so the unit will not appear here while Valeton's editor holds it open.
Grant the permission prompt. Web MIDI asks once per site; if you dismissed it, clear the site permission and reload.
On Windows, close every other browser. Only one program at a time can own a USB-MIDI port there, and a browser holds its ports for as long as it is running. This one looks like a timeout, not like a missing device; the Windows note below has it.
On Linux, check for a sandboxed browser. A Flatpak or Snap Chrome, Chromium, Brave or Edge cannot see USB MIDI at all without one extra grant; the Flatpak note below has the fix.
On Linux, load the ALSA sequencer bridge. This one looks like a broken app rather than a missing driver, so it is worth knowing about; the ALSA note below has the one-line fix.

Windows: another program is holding the MIDI port

Windows gives one program at a time exclusive use of a USB-MIDI port, and a browser claims every port on the machine the moment any page asks for MIDI — then keeps them for the life of the process. So a second browser, or Valeton's editor, or a DAW, quietly takes the pedal away from this tab. The tell is a Response timeout rather than a "not found": listing ports is a separate query that does not open them, so the GP-200 is found, opened, sent to, and simply never answers.

Close the other browser completely. Chrome in particular can outlive its last window — check the system tray, and turn off "Continue running background apps when Google Chrome is closed" in chrome://settings/system. Quit the official editor and any DAW, then unplug and replug the pedal to clear a stuck handle.

If nothing else is running, the browser may be on the WinRT MIDI backend, which is known to hang on exactly the System Exclusive messages this app is built out of. Compare #use-winrt-midi-api in brave://flags or chrome://flags against a browser that does work, set the failing one to match, and relaunch it fully.

Linux: a Flatpak or Snap browser cannot see USB devices

Chromium binds ALSA cards to sequencer clients through udev. A sandboxed browser is handed /dev/snd but not /run/udev, so it drops every card-backed port and keeps only the card-less ones. The tell is a CONNECT message listing Midi Through Port-0 and nothing else: the sequencer is reachable, and the pedal is being filtered out before it gets there. Everything else on the machine — lsusb, aconnect -l, any native app — sees the GP-200 perfectly, which is what makes this one so confusing.

Grant the sandbox read-only udev access: flatpak override --user --filesystem=/run/udev:ro com.brave.Browser. Substitute your own app id — com.google.Chrome, org.chromium.Chromium or com.microsoft.Edge. Then quit the browser completely and reopen it: closing the window is not enough, because the old sandbox stays alive. Force it with flatpak kill com.brave.Browser. To undo the grant, flatpak override --user --nofilesystem=/run/udev com.brave.Browser.

Snap builds have the same shape of problem; connect the relevant interface with snap connect, or install the browser natively. A natively packaged Chrome or Chromium has no sandbox in front of udev and needs none of this.

Linux: the ALSA sequencer bridge is not loaded

Chrome reads Web MIDI from the ALSA sequencer, never from rawmidi directly. Your GP-200 can be listed by lsusb, own a card in /proc/asound/cards and expose a /dev/snd/midiC*D* node while still appearing in no browser at all, because the kernel module that publishes rawmidi devices as sequencer clients (snd-seq-midi) has not been loaded. CONNECT then reports the ports it can see, and the pedal is not among them.

Fix it for this session with sudo modprobe snd-seq-midi, then reload the page (no replug needed). Confirm with grep '^Client' /proc/asound/seq/clients, which should now list a GP-200 client. To survive reboots: echo snd-seq-midi | sudo tee /etc/modules-load.d/snd-seq-midi.conf.

Frequently asked questions

Why does connecting time out in one browser but work in another?: Because on Windows only one program at a time can own a USB-MIDI port, and a browser claims every port on the machine as soon as any page asks for MIDI, then holds them for as long as its process lives. A second browser with GP200 Studio open — or Valeton's editor, or a DAW — takes the pedal away from the one you are looking at. It reads as "Response timeout" rather than "not found", because listing ports does not open them, so the GP-200 is found and simply never answers. Close the other browser completely (Chrome can outlive its last window: check the system tray and turn off "Continue running background apps" in chrome://settings/system), quit the official editor and any DAW, then replug the pedal. If nothing else is running, compare the #use-winrt-midi-api flag between the two browsers — that MIDI backend is known to hang on the System Exclusive messages this app uses — set the failing one to match, and relaunch it.
Which browsers work with the Valeton GP-200?: Chrome or Edge on any desktop OS, and Chrome on Android. Firefox and Safari do not implement Web MIDI, so they can edit and export files but cannot talk to the pedal.
Does it work on Linux?: Yes — anywhere Chrome or Edge runs, including Linux, which the official Valeton editor does not support at all.
Why can't Chrome see my GP-200 on Linux?: Two causes look identical from the browser, and in both the CONNECT message lists only "Midi Through Port-0". Either your browser is a Flatpak or Snap build, which gets /dev/snd but no /run/udev and so drops every USB device, or the ALSA sequencer bridge is not loaded. Fix the first with "flatpak override --user --filesystem=/run/udev:ro <app-id>" and a full browser restart; fix the second with "sudo modprobe snd-seq-midi".
Why does my Flatpak or Snap browser not see any USB MIDI device?: Chromium binds ALSA cards to sequencer clients through udev, and a sandboxed browser is given the /dev/snd device nodes but not /run/udev. Every card-backed port is dropped and only card-less ones like Midi Through survive. Run "flatpak override --user --filesystem=/run/udev:ro com.brave.Browser" with your own app id, then quit the browser completely and reopen it — closing the window is not enough. A natively installed Chrome or Chromium needs none of this.