No OSC packets received from LED Lab

[RealityGrill]

QLC+ 4.11.2
MacOS Sierra 10.12.6 and iOS 11.4

LED Lab is an app which runs on iOS and can broadcast OSC to the destination port 1234.

My aim is to use OSC from LED Lab running on an iPad to trigger scenes in QLC+ running on a MacBook.

I can successfully emit OSC packets from the iPad and inspect them via Wireshark on the Macbook.

I have enabled OSC input in the Input/Output manager in QLC+, and set the input port to 1234, however the joystick icon never appears and the 'Packets Received' field never increments.

How can I debug this further? Is this issue related to the fact that these OSC packets contain double rather than integer or float data?

Thanks,

Here's an example packet trace from Wireshark:

Code: Select all

Frame 81: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0
    Interface id: 0 (en0)
    Encapsulation type: Ethernet (1)
    Arrival Time: Aug 12, 2018 18:07:25.591868000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1534090045.591868000 seconds
    [Time delta from previous captured frame: 0.376400000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 7.268600000 seconds]
    Frame Number: 81
    Frame Length: 70 bytes (560 bits)
    Capture Length: 70 bytes (560 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:osc]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Internet Protocol Version 4, Src: 192.168.1.32, Dst: 255.255.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 56
    Identification: 0xbcbb (48315)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xfc31 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.1.32
    Destination: 255.255.255.255
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 58852, Dst Port: 1234
    Source Port: 58852
    Destination Port: 1234
    Length: 36
    Checksum: 0x4179 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 16]
Open Sound Control Encoding
    Message: /test/example ,d
        Header
            Path: /test/example
            Format: ,d
        Double: 0.5

[mcallegari]

Yes, double is not handled

[EDIT] I installed LED lab, but since NOTHING can be done unless paying at least $19.99, I give up and don't include OSC double support.
Otherwise, please provide a wireshark dump (.pcap) and I'll try and make some blind changes to the code to support doubles

[RealityGrill]

Thanks Massimo,

Here's a temporary link with some example packets in a .pcap file: https://we.tl/24CtLWDGER (this forum prohibited me from attaching that filetype to my post).

LED Lab has the ability to send one, two, or three doubles in a single packet to any user-defined OSC address. Data are always emitted as doubles, regardless of value. I speculate that only supporting the ingestion into QLC+ of packets containing exactly one double would be the simplest solution, and cover many use cases (certainly mine)?

Cheers,

[mcallegari]

Thanks for the file.
I have written the code to support doubles, but I can't test it. Unfortunately I'm not even able to replicate packets on the network the way I want it.

Do you have any chance to build from sources or should I provide you with a OSC plugin for testing ? Which OS do you use ?

[EDIT] Alright, I've been able to test the code and it's working fine. However, I see you can send values like 0.1, 15 or 800!
In the OSC plugin I need to normalize values in a 0-255 range. So, what should I expect to receive as double values ? For floats, I expect them to be between 0.0 and 1.0, so I multiply by 255.

[RealityGrill]

Thanks,

I can possibly build from source with instructions, depending on the toolchain - my QLC+ workspace is on macOS Sierra 10.12.6 although my eventual intent is to load it to QLC+ running on a Raspberry Pi (3 B+, Raspbian Stretch), so presumably I would need to build for that target also.

Regarding the expected values - it seems like we will have to invent a convention and document it, because there's no way to know if an incoming '1' should be normalised to '1' (as if it was an int) or '255' (as if it was a float). Shall we simply expect integers 0-255, round fractions down, and ignore/throw error for inputs outside that range?

A secondary, more complicated option might be to detect the presence of exactly two doubles in the OSC packet, then interpret the first double as being normalised to the range defined by the second. E.G. if the packet contains

Code: Select all

[20.5, 28]

then the value in QLC+ would be interpreted as

Code: Select all

floor(255 * 20.5/28) = 186

What do you think?

[mcallegari]

I think doubles should be similar to floats: the requirement is that they are in the 0.0 - 1.0 range.
Test version for macOS available here: viewtopic.php?f=12&t=3135
Please let me know if QLC+ now works as expected with LED lab

[RealityGrill]

I still cannot receive OSC packets generated by LED Lab into the new QLC+ version.

What did you use as an OSC packet source?

Could you please detail exactly how you configured your OSC plugin input?

[mcallegari]

I have replicated over my LAN exactly the packets in the dump you sent me.
I used tcprewrite and tcpreplay because IP and MAC addresses were obviosuly wrong for me.

So I used LED lab messages. I think the only thiing I changed in QLC+ was the port to 1234.
Also, you need to tell LED lab to send unicast packets and not broadcast to 255.255.255.255

[RealityGrill]

Also, you need to tell LED lab to send unicast packets and not broadcast to 255.255.255.255

This must be the issue. LED Lab unfortunately offers no way of editing the routing structure of the outgoing packets.