Facility Control

 View Only
Expand all | Collapse all

Sending UDP messages as "big-endian".

  • 1.  Sending UDP messages as "big-endian".

    Posted 10-26-2017 09:50

    Hi there! I'm back! :P

    I'm trying to get DashBoard to talk to yet another device. This time, a Behringer X32 Audio Mixer.
    The mixer can recieve OSC commands through network, and since this is basically a formatted UDP message, I tried this node in the Visual Editor in DashBoard.
    So, the mixer does recieve the signal, however it responds with an error message saying it needs to be big-endian formatted.

    From reading through their wiki and looking at more documentation, I found this:

     
    Type rules (get/set parameter) and data formatting
    • all parameters must be big-endian and 4-byte aligned/padded, as per OSC specification.
    • padding is done with null bytes.
    • float parameters must be in range 0.0 – 1.0, e.g:
    0.0 → 0x00000000 (big-endian) 0.5 → 0x3f000000 (big-endian) 1.0 → 0x3f800000 (big-endian)
    • integer and float parameters are signed 32-bit values.
    • boolean parameters will map to OSC integer type.
    • strings must be null-terminated .
    • blobs follow specific rules depending on the section they apply to (see later in this document)

    Now, I might be somewhat of a nerd and do know a bit of code, but this one goes beyond me. Does DashBoard have any way of padding the UDP messages as pr. defined in the rules from the Behringer above?

    See the Behringer X32 Wiki here for more examples etc:
    http://behringerwiki.music-group.com...emote_Protocol

    Kinda curious to see what you come up with here! So far this forum has been golden, so let's see if you got another sweet sollution to this one as well! 



  • 2.  RE: Sending UDP messages as "big-endian".

    Ross Staff
    Posted 10-26-2017 14:02

    All numeric values ogScript and DashBoard parameters are little-endian.
    If you need to convert from one to the other, I would put a "Swap" function in an tag at the top of your panel that you an call to convert from one to the other.

    The only thing you need to know is how many bytes you need to swap. For your use, it would appear that you are always trying to swap 32-bit (4-byte) values.

    function swap32(val) 
    {
        return ((val & 0xFF) << 24)
               | ((val & 0xFF00) << 8)
               | ((val >> 8) & 0xFF00)
               | ((val >> 24) & 0xFF);
    }

    #DashBoard


  • 3.  RE: Sending UDP messages as "big-endian".

    Posted 10-27-2017 07:34
    Hmm, cool! Can definetly give this a go.

    For your last sentence/point there. I am trying to send a value from a slider in DashBoard to the X32 mixer.
    The values go from 0 to 800. But if I'm not wrong (and google dont fail me) I should be able to convert that int. value from little-endian to big-endian with your function above?

    This is beyond what I've been doing before, so sorry if the questions are somewhat redundant.

    EDIT: Reading up on it a bit more and looking through the setup and what I send to the X32, I do send a UDP as a string value.
    More to be specific: [I]"/ch1/fader/level 100"[/I] as an example.
    I assume the entire string has to be converted into big-endian in order to be accepted as an OSC-command.
    I dont have time to test your sollution above until tomorrow. But figured I'd update this anyhow.
    If your sollution above would still work, that's great! If not, do we have any other ideas as to how to do this?

    Giving me a virtual control of physical faders on the sound mixer through DashBoard would be downright epic...
    #DashBoard


  • 4.  RE: Sending UDP messages as "big-endian".

    Posted 10-27-2017 10:34
    That or if you guys just wanna include a "Send OSC" node in your visual editor, that would be even greater!
    #DashBoard


  • 5.  RE: Sending UDP messages as "big-endian".

    Ross Staff
    Posted 10-27-2017 15:01

    If you're sending the message as a UDP String, I'm a little surprised that it cares about the endian-ness of the numbers at all.

    Little vs Big Endian comes into play when you have multiple bytes that make up a value (BYTE is 1 byte, SHORT is 2, INT is 4, and LONG is 8, FLOAT is 4, and DOUBLE is 8)... a string is generally a byte array where each byte is on its own.

    Looking at the OSC Wiki page you linked to, it would appear the messages are expected to be a mix of text and binary numeric data.

    To recreate the one of the example HEX strings they have, I would need to write something like the following:

       /fx/4/par/23~~~~,f~~[float with value 0.5]
        or, in hexadecimal:
        2f66782f342f7061722f3233000000002c6600003f000000 
       
      function bigEBytesFromFloat(number)
      {
      var tempBuilder = ogscript.createMessageBuilder();
      tempBuilder.writeFloat(number);
      var array = tempBuilder.toByteArray();
      var ret = ogscript.createByteArray(4);
      for (var i = 0; i < ret.length; i++)
      {
      ret[i] = array[array.length - i - 1];
      }
      return ret;
      }
       
      var mb = ogscript.createMessageBuilder();
      mb.writeString("/fx/4/par/23");
      mb.writeInt(swap32(0));
      mb.writeString(",f");
      mb.writeByte(0);
      mb.writeByte(0);
      mb.writeByteArray(bigEBytesFromFloat(0.5));

    #DashBoard


  • 6.  RE: Sending UDP messages as "big-endian".

    Posted 10-30-2017 09:25
    Hmm, I see that's where I got confused too...
    The wiki page is the wiki of the mixer (Behringer X32), but so far it's been helpfull (though somewhat confusing at times).

    If I interpret your code above correctly, the function bigEBytesFromFloat creates a BigE version of the integer, the var mb part.. Is that where you take the message and rebuild it into hex?
    #DashBoard


  • 7.  RE: Sending UDP messages as "big-endian".

    Ross Staff
    Posted 10-30-2017 13:10
    In the example I was looking at on the WIKI, the data was of type FLOAT. You won't be able to bit-shift the FLOAT the same way that you would for an INT so that's why I created the new function. If the data type is INT, you could just call the "swap32" function I provided earlier.

    The bigEBytesFromFloat takes the 32-bit (4-byte) FLOAT and reverses the order of the bytes. The result is a BYTE ARRAY we write to our message builder.

    James
    #DashBoard


  • 8.  RE: Sending UDP messages as "big-endian".

    Posted 05-25-2018 16:55

    Hi again @jamespeltzer

    Decided to revisit this one again. And I cant get your bigEBytesFromFloat to work.
    DashBoard throws error messages at me whenever I try that code on a button or something.
    From looking at it, it seems fine to me, so I dont know why DB throws that message, but yeah... Anyways...

    <abs contexttype="opengear" gridsize="20" id="_top">
       <button buttontype="push" height="100" left="60" top="40" width="100">
          <task tasktype="ogscript">function bigEBytesFromFloat(number) {
       var tempBuilder = ogscript.createMessageBuilder();
       tempBuilder.writeFloat(number);
       var array = tempBuilder.toByteArray();
       var ret = ogscript.createByteArray(4);
       for (var i = 0; i &lt; ret.length; i++) {
          ret[i] = array[array.length - i - 1];
      }
      return ret;
    }
      
      var mb = ogscript.createMessageBuilder();
      mb.writeString("/fx/4/par/23");
      mb.writeInt(swap32(0));
      mb.writeString(",f");
      mb.writeByte(0);
      mb.writeByte(0);
      mb.writeByteArray(bigEBytesFromFloat(0.5));</task>
       </button>
       <label height="100" left="180" name="Open debug window and click me..." style="txt-align:west" top="40" width="580"/>
    </abs>

    However, I'm pretty sure I attacked this wrong in the first place. It's looking for a UDP procol OSC message.
    I have found a way to test this without having an actual mixer though if you want to give it a go.
    What I'm after is basically a way to control faders/mute/solo etc on a Behringer X32 through DashBoard faders and buttons. This would make life SO much simpler at our arena it's scary.
    It works now by triggering QLAB through UDB, and have QLAB send OSC messages to the X32, but it's far from optimal.

    Documentation can be found here:
    Wiki: http://behringerwiki.music-group.com...emote_Protocol
    X32 Emulator: https://sites.google.com/site/patrickmaillot/x32 (bullet point 5.1)
    X32 Edit: https://www.musictri.be/Categories/B...0ASF/downloads

    These two programs gives you a virtual X32 for development, and if you start X32 Edit and go to "Setup" (top right) you can connect this to the virtual X32, and SEE changes to the faders etc. Sending the OSC commands from QLAB works just fine, and things react as it should.

    If you want to take a crack at it, and actually give me a working example of a fader in DashBoard that can control fader 1 in the virtual X32... That would be GREATLY appreciated...


    #DashBoard


  • 9.  RE: Sending UDP messages as "big-endian".

    Ross Staff
    Posted 05-25-2018 19:59

    If OSC is what you're looking for, have you tried this example panel I posted a little while ago? It doesn't appear to require changing the endian-ness of the bytes at all:

    <abs contexttype="opengear" style="">
       <meta>
          <params>
             <param access="1" maxlength="0" name="Host" oid="Host" type="STRING" value="localhost" widget="text"/>
             <param access="1" constraint="0.0;65535.0;0.0;65535.0;1" constrainttype="INT_STEP_RANGE" name="Port" oid="Port" precision="0" type="INT32" value="0" widget="spinner"/>
             <param access="1" maxlength="0" name="Message" oid="Message" type="STRING" value="/playbackcontroller/paused " widget="text"/>
             <param access="1" constrainttype="INT_NULL" name="Value" oid="Value" precision="0" type="INT32" value="0" widget="default"/>
          </params>
          <api>function createOSCMessage(cmd, val, isFloat)
       {
          var messageBuilder = ogscript.createMessageBuilder();
       
          var len = cmd.length+1;
          var pad = (4 - len%4)%4;
          var cmdLen = len+pad; // must be integer multiple of 4
          //ogscript.debug ("length: " + len + " pad: " + pad + " = " + cmdLen);
          messageBuilder.writeString(cmd);      
          
          // put null terminator at end of command string
          messageBuilder.writeChar(0); // null terminator
          
          // pad end of command string with nulls
          for (var i=0; i&lt;pad; ++i) 
          {
             messageBuilder.writeChar(0);
          }
            
          // set the 4 bytes that identify the format
          messageBuilder.writeChar(',');
    
          if (isFloat)
          {
             messageBuilder.writeChar('f');
          }
          else
          {
             messageBuilder.writeChar('i');
          }
          
          messageBuilder.writeChar(0);
          messageBuilder.writeChar(0);
          
          
          // tack on the value
          if (isFloat)
          {
             messageBuilder.writeFloat(val);      
          }
          else
          {
             messageBuilder.writeInt(val);  
          }
          return messageBuilder.toByteArray();
    }
    
    function sendOSCMessageInt(ip, port, cmd, val)
    {
       ogscript.sendUDPBytes(ip, port, createOSCMessage(cmd, val, false));
    }
    
    
    function sendOSCMessageFloat(ip, port, cmd, val)
    {
       ogscript.sendUDPBytes(ip, port, createOSCMessage(cmd, val, true));
    }
    </api>
       </meta>
       <table height="367" left="21" top="19" width="493">
          <tr>
             <label colspan="2" fill="both" insets="2,2,2,2" name="Send OSC Command" rowspan="1" style="txt-align:center;bg#dark;size:Bigger;font:bold;" weightx="1.0" weighty="1.0"/>
          </tr>
          <tr>
             <label colspan="1" fill="both" insets="2,2,2,2" name="Host: " rowspan="1" style="txt-align:east;" weighty="1.0"/>
             <param colspan="1" expand="true" fill="both" insets="2,2,2,2" oid="Host" rowspan="1" weightx="1.0" weighty="1.0"/>
          </tr>
          <tr>
             <label colspan="1" fill="both" insets="2,2,2,2" name="Port: " rowspan="1" style="txt-align:east;" weighty="1.0"/>
             <param anchor="west" colspan="1" expand="true" fill="vertical" insets="2,2,2,2" oid="Port" rowspan="1" weightx="1.0" weighty="1.0"/>
          </tr>
          <tr>
             <label colspan="1" fill="both" insets="2,2,2,2" name="Message: " rowspan="1" style="txt-align:east;" weighty="1.0"/>
             <param colspan="1" expand="true" fill="both" insets="2,2,2,2" oid="Message" rowspan="1" weightx="1.0" weighty="1.0"/>
          </tr>
          <tr>
             <label colspan="1" fill="both" insets="2,2,2,2" name="Value: " rowspan="1" style="txt-align:east;" weighty="1.0"/>
             <param anchor="west" colspan="1" expand="true" fill="vertical" insets="2,2,2,2" oid="Value" rowspan="1" weighty="1.0"/>
          </tr>
          <tr>
             <button buttontype="push" colspan="2" fill="both" insets="2,2,2,2" name="Go! (Float)" rowspan="1" weightx="1.0" weighty="1.0">
                <task tasktype="ogscript">/*! block id=1005,1001,1002,1003,1004 !*/
    sendOSCMessageFloat(params.getValue('Host', 0), params.getValue('Port', 0), params.getValue('Message', 0), params.getValue('Value', 0))
    /*!!
     &lt;block id="1005" type="function_sendOSCMessageFloat" x="283" y="10" w="243" ip="ID:1001" port="ID:1002" cmd="ID:1003" val="ID:1004" /&gt;
    &lt;block id="1001" type="param_Host (Host)[0]" x="10" y="10" w="243" SET="" /&gt;
    &lt;block id="1002" type="param_Port (Port)[0]" x="10" y="72" w="243" SET="" /&gt;
    &lt;block id="1003" type="param_Message (Message)[0]" x="10" y="134" w="243" SET="" /&gt;
    &lt;block id="1004" type="param_Value (Value)[0]" x="10" y="196" w="243" SET="" /&gt;
    !!*/
    /*!!&lt;checksum&gt;37e85f509c16c798f6976597013f4ce2&lt;/checksum&gt;!!*/</task>
             </button>
          </tr>
          <tr>
             <button buttontype="push" colspan="2" fill="both" insets="2,2,2,2" name="Go! (Int)" rowspan="1" weightx="1.0" weighty="1.0">
                <task tasktype="ogscript">
    
    
    /*! block id=1006,1001,1002,1003,1004 !*/
    sendOSCMessageInt(params.getValue('Host', 0), params.getValue('Port', 0), params.getValue('Message', 0), params.getValue('Value', 0))
    /*!!
     &lt;block id="1006" type="function_sendOSCMessageInt" x="283" y="10" w="243" ip="ID:1001" port="ID:1002" cmd="ID:1003" val="ID:1004" /&gt;
    &lt;block id="1001" type="param_Host (Host)[0]" x="10" y="10" w="243" SET="" /&gt;
    &lt;block id="1002" type="param_Port (Port)[0]" x="10" y="72" w="243" SET="" /&gt;
    &lt;block id="1003" type="param_Message (Message)[0]" x="10" y="134" w="243" SET="" /&gt;
    &lt;block id="1004" type="param_Value (Value)[0]" x="10" y="196" w="243" SET="" /&gt;
    !!*/
    /*!!&lt;checksum&gt;7ad40349f4a60fbeaab59c3f232b9b10&lt;/checksum&gt;!!*/</task>
             </button>
          </tr>
       </table>
    </abs>

    #DashBoard


  • 10.  RE: Sending UDP messages as "big-endian".

    Posted 05-25-2018 21:19

    THERE WE GO!!!!
    That solved it all!!!

    Sorry, I trusted the wrong source months ago when I asked for remote protocols for the X32.
    I was told I could use UDP commands, but it had some issues with the big-endian vs little-endian.

    However reading up today, it turns out it's OSC commands of course through a UDP protocol (it really wasnt THAT important months ago). And that in itself gives the commands a different set!
    It works! Thanks ALOT! This is gonna make my DashBoard so much better!

    If you want you can change the title on this one to "Control device over OSC".

    Now... To get the UDP response from the mixer. So that if/when I have a mute button I can actually set it to it's correct state if it's pressed by whoever sits in front of the mixer. That and meter values.

    Anyhow, I've made a UDP listener as below:

    <listener autostart="true" listenport="10023" maxlength="1024" name="UDP Listener" udp="true">
       <task tasktype="ogscript">if (event.getEventType() == 1)
    {
       ogscript.debug('Recieved something...');
       ogscript.debug(event.getBytesAsString());
    }</task>
    </listener>

    Now this doesnt give me anything. Wrong port most likly. And this is where I'm lost once again. The X32 OSC/UDP Manual states that:

    • In the following, the X32 (rack, console) is also called server, and a connected device or application is typically called client. Connections to the server take place over Ethernet network, UDP port 10023. The server replies on the UDP port specified by the client when establishing communication.


    "The server replies on the UDP port specified by the client when establishing communication."...

    But as far as I can tell I dont specify this at all? Is this something DashBoard specifies by default? Or is there something I'm missing here?


    #DashBoard


  • 11.  RE: Sending UDP messages as "big-endian".

    Ross Staff
    Posted 05-28-2018 13:39

    If you need to receive a response on the same UDP port, you'll want to use a UDP Listener. You can access the listener and send UDP messages from its port.

    Posted below is an example to work from:

    <abs contexttype="opengear">
       <meta>
          <listener autostart="true" listenport="2345" maxlength="1024" udp="true">
             <task tasktype="ogscript">
             //THIS IS FAKING THE SERVER - YOU WON'T NEED THIS LISTENER SINCE THIS SIDE WILL BE DONE BY YOUR OSC DEVICE
             if (event.isMessageEvent())
    {
       var myString = event.getBytesAsString() + "";
       var response = "";
       for (var i = myString.length - 1; i &gt;= 0; i--)
       {
          response += myString.charAt(i);
       }
    
       this.writeString(response, false); //Write a response back to the port on which the message was sent
       
    }</task>
          </listener>
          <listener autostart="true" id="listener-to-send-through" listenport="1234" maxlength="1024" udp="true">
             <task tasktype="ogscript">
             //THIS LISTENER ALLOWS YOU TO SEND/RECEIVE UDP ON THE SAME PORT - SEND IS DONE THROUGH BUTTON
             if (event.isMessageEvent())
    {
       ogscript.debug("GOT RESPONSE: " + event.getBytesAsString());
    }</task>
          </listener>
       </meta>
       <button buttontype="push" height="148" left="21" top="18" width="219">
          <task tasktype="ogscript">var listener = ogscript.getListenerById("listener-to-send-through");  //GET THE LISTENER AND SEND DATA THROUGH IT
    listener.sendUDPString("localhost", 2345, "Hello World"); //REPLACE localhost/2345 WITH YOUR OSC IP ADDRESS AND PORT </task>
       </button>
    </abs>

    #DashBoard


  • 12.  RE: Sending UDP messages as "big-endian".

    Ross Staff
    Posted 05-28-2018 13:42
    Note: The UDP Listener also supports:
    listener.sendUDPBytes(HOST, PORT, BYTE_ARRAY);
    and
    listener.sendUDPAsBytes(HOST, PORT, BYTE_ARRAY_ENCODED_AS_STRING)
    #DashBoard


  • 13.  RE: Sending UDP messages as "big-endian".

    Posted 05-29-2018 11:21
    Yes I've seen your previous examples of a UDP listener, and have had great success with those in other areas.
    However I dont know what port to listen to anymore. As mentioned above, the X32 documentation states that "The server replies on the UDP port specified by the client when establishing communication."

    Now I honestly dont know OSC good enough to know what part of the command would specify what I want as a return port, and neither can I find a specification for it in the X32 documentation either.
    It would just be awesome to be able to /subscribe to X32 changes and get a live metering for channels and fader positions from the X32 live updated back into the DashBoard. So to communicate both ways.

    I'm also a little stuck on another OSC application issue. This time around it's QLAB.
    QLABs control is based upon OSC on port 53000, and if it has a response it replies on 53001.
    However it also reacts to simple UDP strings sent to port 53535. However this does not trigger a response on port 53001...

    I tried your example from earlier, and just change the ports and command etc to see if I could use this for QLAB OSC protocol as well, but for some reason that does not work.
    You can see the QLAB OSC documentation here: http://figure53.com/docs/qlab/v4/scripting/osc-dictionary-v4/

    #DashBoard


  • 14.  RE: Sending UDP messages as "big-endian".

    Ross Staff
    Posted 05-29-2018 15:14
    In past experiences with OSC, either the application has a configurable outgoing host/port or it just replies on whichever port number the message originated from. If it is the later, you'd want to use the send-through-listener approach from the example I posted above (and which you are already familiar with). I'm not aware of any port specification command.

    For you QLAB issue, do you have to specify an outgoing host name for the reply messages?

    James


    #DashBoard


  • 15.  RE: Sending UDP messages as "big-endian".

    Posted 02-18-2019 22:57

    So... I fixed the QLAB OSC message thingy, and I got that to work...

    So I decided to once again, look into connecting to a Behringer X32 with this... Now I have no problem actually controlling it through OSC messages, and I can get the commands going real easy like. Faders react, and they move up and down, mute or go solo as I wish. All good!

    BUT!!!

    I really really REALLY want this to be a two way communication. So that I can see on my DashBoard what the user behind the X32 is doing to the faders etc. As in, update buttons and values for mute, and move my faders on DashBoard up and down as he/she does.
    But I just cant wrap my head around it! And it just doesnt want to do what it's supposed to do...

    Now, for the Behringer X32, there is an emulator, that just basically gives you a cmd window with the OSC messages going in and out.
    But you CAN connect to it with the X32 software.
    You can find the emulator here:
    https://sites.google.com/site/patrickmaillot/x32#TOC-X32-emulator

    And the X32 software from Behringer, the X32 Edit, you can find here:
    https://www.musictribe.com/Categories/Behringer/Mixers/Digital/X32/p/P0ASF/downloads?active=Downloads

    Now... If you run the X32 emulator, and start the X32 Edit, go to "Setup" in the X32 Edit, and you can scan for X32 devices on your network. You should get one with the same IP as you have in the list. Connect to it, and select if you wanna sync from the "mixer" or from the PC. I suggest PC -> Mixer. Once that is done, you can move one of the faders on the X32 Edit, and you can see the console value change in the X32 Emulator.

    Now... This here is just a simple DashBoard with one fader... Sending an OSC message by a message builder, through a listener as @jamespeltzer suggested above. And as you might see [I](IP is set to localhost, port is 10023)[/I], if you move it, the channel 5 fader on the X32 Edit should change, and you can see the values in the X32 Emulator as well.
    And I can confirm that this is a working code, as it does work on a physical X32 as well.

    Now, according to the documentation made by the same guy that makes the emulator [I](no, not official, but reading up and seeing his stuff, this is correct)[/I], there should be a message that is /xremote that basically sends out what happens to the mixer to the software that sent the /xremote command.

    See documentation here: https://sites.google.com/site/patrickmaillot/docs/X32-OSC.pdf?attredirects=0

    But from the DashBoard I have, I get nothing back in the listener? Neither by just using the fader, or by sending the /xremote first. I dont even get a response back from the emulator that it's reacted to the /xremote even.
    Is there anyone out there, that is able to wrap their noggins around this one? I sure would be greatly appreciative!
    Been butting heads with this one for a while now...

    Example DB:

    <abs contexttype="opengear" gridsize="20" id="_top">
       <meta>
          <params>
             <param access="1" constraint="0.0;1024.0;0.0;1024.0;1" constrainttype="INT_STEP_RANGE" name="volume" oid="volume" precision="0" type="INT32" value="0" widget="slider-vertical-nolabel"/>
          </params>
          <listener autostart="true" id="x32listener" listenport="10023" maxlength="1024" name="OSC X32 Listener" udp="true">
             <task tasktype="ogscript">if (event.getEventType() == 1)
    {
       ogscript.debug('Recieved something...');
       ogscript.debug(event.getBytesAsString());
    }</task>
          </listener>
       </meta>
       <meta>
          <api immediate="true">function createOSCMessage(cmd, val, isFloat) {
       var messageBuilder = ogscript.createMessageBuilder();
       var len = cmd.length+1;
       var pad = (4 - len%4)%4;
       var cmdLen = len+pad;
       messageBuilder.writeString(cmd);      
       messageBuilder.writeChar(0); // null terminator
       for (var i=0; i&lt;pad; ++i) {
          messageBuilder.writeChar(0);
       }
       messageBuilder.writeChar(',');
       if (isFloat) {
          messageBuilder.writeChar('f');
       } else {
          messageBuilder.writeChar('i');
       }
       messageBuilder.writeChar(0);
       messageBuilder.writeChar(0);
       if (isFloat) {
          messageBuilder.writeFloat(val);      
       } else {
          messageBuilder.writeInt(val);  
       }
       return messageBuilder.toByteArray();
    }
    
    function sendOSCMessageInt(ip, port, cmd, val) {
       ogscript.sendUDPBytes(ip, port, createOSCMessage(cmd, val, false));
    }
    
    function sendOSCMessageFloat(ip, port, cmd, val) {
       ogscript.sendUDPBytes(ip, port, createOSCMessage(cmd, val, true));
    }</api>
       </meta>
       <param expand="true" height="500" left="80" oid="volume" top="60" width="100">
          <task tasktype="ogscript">sendOSCMessageInt('localhost', '10023', "/ch/05/mix/fader", params.getValue('volume', 0));</task>
       </param>
       
    </abs>

    #DashBoard


  • 16.  RE: Sending UDP messages as "big-endian".

    Ross Staff
    Posted 03-08-2019 17:21
    Hi @astalsberg
    Just circling-back to this question. Have you verified whether or not something else is already running as a server on port 10023? This would prevent the DashBoard custom panel from binding-to/listening-on that port.

    James
    #DashBoard


  • 17.  RE: Sending UDP messages as "big-endian".

    Posted 03-11-2019 13:16
    Hi @astalsberg
    Just circling-back to this question. Have you verified whether or not something else is already running as a server on port 10023? This would prevent the DashBoard custom panel from binding-to/listening-on that port.

    James


    Fair point... No I have not yet done this. But this just might be the whole reason it fails when I'm testing... Seeing as I'm allready running the X32 Emulator on the same PC, I guess that one would allready take the port in question. Gonna have to try at home with two PCs.
    We're getting close to the end of the season anyhow now, and we're gonna do a complete remake of the entire system, so I'll have plenty time to test it with the actual mixer as well.

    Thanks though!
    Will get back to you on how this went!
    #DashBoard