search

DMXCore / DmxCore100

DMX Core 100 - Standalone Controller
0 stars 0 forks source link

Consider Broadcast/multicast vs Unicast playback #9

Open VividRGBLighting opened 1 year ago

VividRGBLighting commented 1 year ago

Looking at recorded packets in wireshark - packets appear to be recorded as multicast, but I'm not sure how to record a unicast stream of data because by default the device would not receive the unicast packets as the IP address would not match. Our sACN drivers will only accept 7 universes of data in multicast, but 12 universes in unicast.

As such, it maybe required to record a show in multicast and then play it back in unicast.

HakanL commented 1 year ago

For the packets to make it to the DMX Core they have to be sent either multicast, or unicast directly to the DMX Core, there aren't really any ways around that. The sACN code I have does support unicast output, however I haven't exposed any of that confirmation in the UI, need to figure out a good way to do that and have the appropriate priority for the work. It's possible that renaming the "Port config" to mapping, and just having there as an IP input field could work. And you could just have multiple ports, one for each unicast destination.

VividRGBLighting commented 1 year ago

I like the Mapping term. Perhaps there needs to be "Input Mapping" and "Output Mapping" Not sure what the options are. Also not sure the workflow - ie, is it beneficial to map the Input/output together? Or is it ok to deal with the Inputs on one page and then outputs on another.

Can you have a "one to many" IE: Input universe 3 is sent to output universe 5,6,7? (Where 5 & 6 are DMX)

If so then I think separate them.

INput mapping: Receive universe: 9 Saved as DMXCore Universe: 3

Output Mapping: (Either listed as the ports, or by DMXCore Universe):

DMX Output 1: DMXCore Universe 3 DMX Output 2: DMXCore Universe 3 sACN Output: DMXCore Universe 3 DMXCore Universe 8 DMXCore Universe 4

In the bigger sense, I'm not sure I see the benefit of revealing the internal universes to the user. It seems to be more of an internal housekeeping thing. (I guess the idea would be that I could record the same input universe to multiple DC Slots and then play them all back together) SO I could record Universe 3 into DC Slot 1, Then a different cue still on universe 3 into DC Slot 2 and then write a cue that would play them both back at the same time but to two different output universes? This seems like a outlier of a use case to me - but maybe not.

HakanL commented 1 year ago

Yeah, I think you're onto something, it is essentially mapping. And yes, you can map internal "slot 1" to output to sACN universe 3 and DMX port B, for example. In your question about concurrent playback, so that's not something I have currently in the engine, it only does one concurrent playback stream, but it could be implemented if I see the use case.