Announcement

Collapse
No announcement yet.

Is there a more efficient way to do this?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is there a more efficient way to do this?



    So I have this feature working perfectly but it is a little arduous to setup, especially because I have to do this for about 10-20 different functions. You can see that I demultiplexed an incoming OSC message from my software and then applied a MIDI template event to each incoming message. To do this required 12 MIDI templates for the 11 lights (plus off) and then spreading those out across 101 (including 0) incoming OSC messages.

    A little explanation, my lighting software sends several messages that OSCulator is receiving like this

    /eos/out/wheel/1
    /eos/out/wheel/2 etc. etc.

    these messages can send several things, wheel 2 can send several values like /eos/out/wheel/2/[Red] 24, /eos/out/wheel/2/[Pan] 212, /eos/out/wheel/2/[Cyan] 14

    I demultiplexed it so that I could separate out the various messages and then make them output a MIDI cc that corresponds with the specific light that I want to light up around my encoders. I was just wondering if I can do this without demultiplexing.

    An Idea I had was to use substitutions but (Understandably) there is no info on this as the version 3 manual isn't out and I couldn't figure it out by reading on the forums. I don't entirely get how it works but it sounds like it could potentially be a solution? I would need to subsitute the MIDI CC velocity with the argument from the OSC message but with one only for red, one for pan etc.

    It would be much better to do it this way because I would only have to toggle off one event and trigger on one other event to change the midi template from red to pan. Right now I would have to toggle off 101 events and then toggle on 101 events to switch from red to cyan.

    Again I don't know if this is possible already

  • #2
    Hi Fornez,

    I had a quick look at the EOS Family user manual (EosFamily_ShowControl_UserGuide_RevC.pdf, not sure if the manual is appropriate). I can see there are two possible message for the wheel encoder:
    - page 61 : the one you describe, /eos/out/active/wheel/<number>, this one does not seem to send the current value.
    - page 53 : another format, /eos/out/active/wheel<number>, the third argument is the current value.

    When the value is in the string like "[Red] 12", or "[Pan] 14", there's not much you can do. For me it does not looks like something that was designed to be used as a control value, but as a display value (e.g. to used with text field on touch surfaces).

    If you can find a way to get the value (12) separated from the label ("Red"), then doing what you suggest would become easy.

    I don't know enough the lighting product you are using to tell if that is possible; in OSCulator there's no way to parse those strings.

    (As I was unsure if the manual I read was the good one, I attached it to this post, for reference.)

    Best,
    Cam
    Attached Files

    Comment


    • #3
      Ok I think that settles it then, as you described the problem is separating the label from the value since it sends the whole thing together. I don't think there is a way for me to change how the string is sent. At least I know that I can still make it work though.

      My only question is how will the app perform when sending what may end up being 100-500 enable commands at a time with one button press? (I think I will have to put them all in there for each button)

      And that is the correct user manual sorry I could have sent that myself, it's the exact one i'm using

      Comment


      • #4
        I don't think there is a way for me to change how the string is sent.
        How do you explain there are two different messages format?
        If you could use the one with the value as a number, then you could setup a leaner solution.

        My only question is how will the app perform when sending what may end up being 100-500 enable commands at a time with one button press? (I think I will have to put them all in there for each button)
        Sorry I missed this question. I honestly can't answer precisely as I never met this order of magnitude. I believe this should not pose too much problem, though I would test on a small scale to begin with. I will have a look on my side and let you know. As you might have understood, if you can find a more lightweight solution on the controller side, we wouldn't have to be worried about performance...


        Best,
        Cam

        Comment


        • #5
          I'm not seeing a difference between those two messages I think that page 61 may just be a more in depth description of page 53, I'm not sure though.

          I'm gonna wait to start setting up those enable commands until later when I have some more features finished. When I do I'll let you know how well it works.

          There is some other weird stuff though that I don't think is worth making a thread about. Here's another video



          This is me moving the fader on my controller, the top left is OSCulator and the bottom left is an app called Luminosus. Luminosus was made to work with midi controllers but it is not nearly as versatile as OSCulator. Luminosus is also specifically designed to work the ETC nomad software I'm using. The top right is the output of ETC nomad.

          You can see that Nomad is outputting the fader position as /eos/fader/1/1, <arg>
          Luminosus is reading that as /eos/fader/1/1,<arg>
          But the only thing in OSCulator is showing up as /eos/out/active/cue/text. When I demux that I see it show up as a bunch of numbers, it should be a big list of labels. I checked the ETC forums to ask about why it wasn't sending the fader message but I think it might be that OSCulator is not receiving it somehow?

          Also you can see that there are a bunch of messages "/eos/out/active/cue" that seems to me like they would usually be collapsed but they are all separate messages.

          So I don't really know what all this behavior means for OSCulator

          Screen Shot 2018-02-19 at 7.53.32 PM.png Screen Shot 2018-02-19 at 8.15.31 PM.png These are my settings in Nomad, I never needed to set the string tx or rx ports before but I changed them to 8000 just to see if it did anything. The OSC tx I.P address is set to my computers IP address (it's 0.0.0.0 so I could share it).
          Last edited by Fornez; 02-20-2018, 04:00 AM.

          Comment


          • #6
            btw if this is something wrong with OSCulator and you want to test it you can download the light software for free here "Eos ETCnomad MAC Software v2.6.4"

            and then send it an OSC message of /eos/subscribe with a token of 1

            after that you can click the arrow at the bottom and choose, setup, diagnostics, then turn outgoing OSC on. Then click the faders module near the bottom of the window with all the icons

            Then the software will start outputting the fader position to OSCulator

            edit- some more info, you can setup the light software and OSCulator according to this minus the qlab part MIDI Notes to OSC.pages - ETC - Community
            Last edited by Fornez; 02-20-2018, 11:03 AM.

            Comment


            • #7
              I can see what is happening, but I honestly don't understand how that can be possible.

              Here is what I got (I don't have a dongle, so I believe this explains why I can't get receive fader messages):


              As you can see the /eos/out/active/cue/text message has been received with a string argument (the empty string "", I don't know how to give cues a name).

              Note (and I don't think this has to do with the problem described)) that you are using OSCulator with a UDP connection, therefore you shouldn't need to call /eos/subscribe if you're on UDP and you shouldn't need to configure OSC RX and TX ports.

              So, for me the settings were are follow:
              EOS-2.png

              ... basically no setting.

              Then, from OSCulator, I sent /eos/subscribe 1 to the OSC target with address osc.tcp://localhost:3032. (3032 is the default port). I won't go into too much details, but basically, I had a hard time making this OSC TCP connection work properly. Unfortunately this is not a feature that is often used.

              I have prepared a new beta build, which includes a fix to OSC over TCP. Again, I am pretty sure this is not the reason of the confusion you reported, but I thought that it would be better to avoid mixing protocols in your setup. Please download it here: https://osculator.net/download and be sure to pick the beta version.

              Best,
              Cam

              Comment

              Working...
              X