I'm developing a macOS application that communicates with Eos consoles via OSC. I rely on the patch UID (the UUID returned as argument 1 in /eos/out/get/patch/<chan>/<part>/list/ responses) as a stable identifier to track channels across reconnects and renumbering. I've discovered that undo of any patch operation regenerates UIDs for the entire patch. This behavior is problematic and seems unintentional.
Methodology
I connected via OSC (TCP, localhost:3032) and enumerated all patch channels using /eos/get/patch/count followed by /eos/get/patch/index/0 through /eos/get/patch/index/N. I extracted the UID from each response and compared them across the following operations. Test show had 37 patched channels (Generic Dimmers, GLP Impression X5 M2, ETC ColorSource PAR, Martin Mac Viper Performance, Martin Mac Encore CLD).
Test Sequence
1. Baseline scan - recorded UIDs for all 37 channels
2. Moved all channels +100 (Chan 1 Thru 46 Move To Chan 101)
3. Moved all channels back (Chan 101 Thru 147 Move To Chan 1)
4. Undid non-patch commands
5. Undid the patch move (step 3)
6. Edited label on Chan 1 ("Fronts" to "FrontsTEST")
7. Undid the label edit
Results
Steps 2 and 3 (moves): All UIDs preserved. Channel objects survive renumbering. Eos also created empty Generic Dimmer channels to fill gaps in the destination range.
Step 4 (non-patch undo): No UID changes. Patch is untouched.
Step 5 (patch undo): Every single UID regenerated. All 37 channels received brand new UIDs.
Step 6 (label edit): UID preserved. Metadata changes don't affect UIDs.
Step 7 (label undo): Every single UID regenerated again. Even undoing a trivial label change reconstructs the entire patch.
Tracking Chan 1 Through the Entire Test
Original: 99786344-8109-49B1-9D5D-FDFD5E6CDDA0
After move to Chan 101: 99786344 (same)
After move back to Chan 1: 99786344 (same)
After non-patch undo: 99786344 (same)
After patch undo: 29C1A120-6A1E-4501-BEA7-3223A9BC768D (NEW)
After label edit: 29C1A120 (same)
After label undo: 5FBAE0C7-867C-40E8-8047-6B27F15DE912 (NEW)
Sample UIDs Before vs After a Single Patch Undo
Chan 1: 99786344 → 29C1A120 (changed)
Chan 2: 9206BA3A → 3F186544 (changed)
Chan 3: C1BCF341 → 8DFC99F8 (changed)
Chan 4: 9241CF65 → 1A63D544 (changed)
Chan 11: D84B2303 → 25AF215F (changed)
Chan 14: 9BFD8BA0 → BB749F15 (changed)
Chan 21: 2693A6C2 → EEA7C846 (changed)
Chan 31: 532E4054 → (changed)
Chan 1001: EBC14629 → (changed)
Every channel in the patch was affected.
Summary
Move: preserves UIDs
Label/metadata edit: preserves UIDs
Non-patch undo: preserves UIDs
Any patch undo (even trivial): regenerates ALL UIDs for every channel
Is UID regeneration on patch undo intentional behavior? It seems like the undo system could just keep the original UIDs along with the rest of the channel data. Preserving UIDs across undo would make third-party integrations significantly more robust.
Tested on Eos Family v3.3.5.