• State Not Answered
  • Date
    micecakes
  • Date
  • Replies 3 replies
  • Subscribers 66 subscribers
  • Views 983 views
  • Users 0 members are here
Options
Related

Can I assign my encoders to specific encoders in nomad?

I’m pretty sure the answer is no, however i’m not completely certain if the documentation is still up to date but has ETC or anyone else found a way to let my encoders be parameter agnostic and follow whatever is on the encoder page selected on the desk eg. focus page and colour page? This would be incredibly useful as I am looking to essentially create a programming wing replica minus the faders.

The only promising thing I have found is this video:

youtu.be/2jeyQjmPyMM

where the person reverse engineers a programming wing, Unfortunately I have neither a programming wing nor the expertise/time required to achieve something like this. If anyone has any suggestions or even code that works similarly to that shown in the youtube video I would greatly appreciate your help.

Sorry for the long post (and the second in a few days)

  • 0

    There are many useful things that can be done using the OSC interface but emulating a programming wing is not one of them.

    The diagnostic tab (tab 99) is a useful tool for understanding what is available to  you via OSC. Turn on monitoring for outgoing OSC.

    This snippet of the log captures typing 1+41+61<ENTER> on the command line where 1 is a dimmer, 41 is a Desire D40 Vivid, and 61 is a scroller/dimmer.

    As channel selection changes, Eos sends /eos/out/active/chan and /eos/out/active/wheel information. However, it does not send any information about which wheels are visible on the display. Neither does it send any user interactions with the encoder display so it is not possible to make reliable guesses about what might be on the display at any given time.


    OSC 2024-04-14 10:18:59.778 [Global/UDP] SEND [OSC Packet] /eos/out/cmd, LIVE: Cue 2 / 1 : Chan 1 + (s), 0(i)
    OSC 2024-04-14 10:18:59.778 [Global/UDP] SEND [OSC Packet] /eos/out/active/chan, 1 [20] Front Generic Front_Light @ 1(s)
    OSC 2024-04-14 10:18:59.778 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/1, Intens [20](s), 1(i), 20.000(f)
    OSC 2024-04-14 10:18:59.778 [Global/UDP] SEND [OSC Packet] /eos/out/color/hs, 35.818(f), 16.983(f)
    OSC 2024-04-14 10:19:16.903 [Global/UDP] SEND [OSC Packet] /eos/out/user/1/cmd, LIVE: Cue 2 / 1 : Chan 1 + 4(s), 0(i)
    OSC 2024-04-14 10:19:16.903 [Global/UDP] SEND [OSC Packet] /eos/out/cmd, LIVE: Cue 2 / 1 : Chan 1 + 4(s), 0(i)
    OSC 2024-04-14 10:19:17.428 [Global/UDP] SEND [OSC Packet] /eos/out/user/1/cmd, LIVE: Cue 2 / 1 : Chan 1 + 41(s), 0(i)
    OSC 2024-04-14 10:19:17.428 [Global/UDP] SEND [OSC Packet] /eos/out/cmd, LIVE: Cue 2 / 1 : Chan 1 + 41(s), 0(i)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/user/1/cmd, LIVE: Cue 2 / 1 : Chan 1 + 41 + (s), 0(i)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/cmd, LIVE: Cue 2 / 1 : Chan 1 + 41 + (s), 0(i)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/chan, 1,41 [20] Front Generic Front_Light @ 1(s)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/2, Red [30](s), 3(i), 29.574(f)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/3, Red Orange [0](s), 3(i), 0.000(f)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/4, Amber [98](s), 3(i), 98.488(f)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/5, Green [100](s), 3(i), 100.000(f)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/6, Blue [14](s), 3(i), 14.233(f)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/7, Indigo [14](s), 3(i), 14.207(f)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/8, Cyan [25](s), 3(i), 25.381(f)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/9, Hue [42](s), 3(i), 42.407(f)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/10, Saturation [70](s), 3(i), 69.651(f)
    OSC 2024-04-14 10:19:20.878 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/11, Shutter Strobe [0](s), 5(i), 0.000(f)
    OSC 2024-04-14 10:19:21.553 [Global/UDP] SEND [OSC Packet] /eos/out/user/1/cmd, LIVE: Cue 2 / 1 : Chan 1 + 41 + 6(s), 0(i)
    OSC 2024-04-14 10:19:21.553 [Global/UDP] SEND [OSC Packet] /eos/out/cmd, LIVE: Cue 2 / 1 : Chan 1 + 41 + 6(s), 0(i)
    OSC 2024-04-14 10:19:22.153 [Global/UDP] SEND [OSC Packet] /eos/out/user/1/cmd, LIVE: Cue 2 / 1 : Chan 1 + 41 + 61(s), 0(i)
    OSC 2024-04-14 10:19:22.153 [Global/UDP] SEND [OSC Packet] /eos/out/cmd, LIVE: Cue 2 / 1 : Chan 1 + 41 + 61(s), 0(i)
    OSC 2024-04-14 10:19:31.783 [Global/UDP] SEND [OSC Packet] /eos/out/user/1/cmd, LIVE: Cue 2 / 1 : Chan 1 + 41 + 61 #(s), 0(i)
    OSC 2024-04-14 10:19:31.783 [Global/UDP] SEND [OSC Packet] /eos/out/cmd, LIVE: Cue 2 / 1 : Chan 1 + 41 + 61 #(s), 0(i)
    OSC 2024-04-14 10:19:31.783 [Global/UDP] SEND [OSC Packet] /eos/out/active/chan, 1,41,61 [20] Front Generic Front_Light @ 1(s)
    OSC 2024-04-14 10:19:31.783 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/9, Scroller [1](s), 3(i), 0.500(f)
    OSC 2024-04-14 10:19:31.783 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/10, Hue [42](s), 3(i), 42.407(f)
    OSC 2024-04-14 10:19:31.783 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/11, Saturation [70](s), 3(i), 69.651(f)
    OSC 2024-04-14 10:19:31.783 [Global/UDP] SEND [OSC Packet] /eos/out/active/wheel/12, Shutter Strobe [0](s), 5(i), 0.000(f)

  • 0

    The OSC interface protocol currently has no method to duplicate the encoders in the console.  The best you could do would be program a light hack that takes the current wheels as they are output and sorts them into their appropriate category based on the wheel info as it is transmitted.  This would allow you to have an appearance that is similar to what you get on the console.  Unfortunately this will not work when a mixed group of fixtures is selected as each one has a different order to the wheels.  I still currently build out encoder layouts per category for what I use the device/interface for.  When you build your own you are also not locked into one category at a time and can mix and match for what you want to have control of.  

    Hope this helps

  • 0

    hi, glad you liked my video :)

    I didn't manage to find any other way to do what I (and you!) wanted; however the reverse engineered solution has been rock solid for me. (Ironically, the OSC part of my homebrew console, which handles key presses, is less reliable. Probably my fault somehow, but looking into it requires time and effort.)

    Regarding not having a programming wing… I hired one! It meant I had a deadline, as I had to get all the data I needed in one weekend!

    I don't mind sharing some notes and my code if it's any use, but it comes with the big caveats of: it's not a drop in solution for other hardware -- I built it for the Teensy 3.5, which is no longer sold, and my modifications to the Teensy's USB library are model specific. Also, my system uses three Teensies talking via I2C to handle different bits of the board, so you'd need to rip all of the I2C code out. And while I don't mind discussing a few things over Messenger, I probably won't have the time to do detailed hand-holding through building something. That said, I have helped one other person build one… but they were someone who worked at the same place as me so we were able to meet in person (and on work time, which helped!)

    Feel free to drop me a message Slight smile

    Amy

www.etcconnect.com