Custom mapping RGB to RGBWAUv?

[Grant Patterson]

Hi there, I'm wondering if OLA is a good solution for mapping openpixelcontrol data in RGB to DMX RGBWAUv fixtures. Is there a straightforward way to process the 3-channel RGB data into 6-channel RGBWAU (using custom mappings of my choosing; I'll do the math etc.)?

Long story:

I have a webapp that outputs openpixelcontrol packets to FadeCandy, which supports OPC over websockets. I can use websockify to forward the websocket data to a local port, which I assume OLA can handle like any other OPC receiver. Then I want to look at the hue and saturation values of each RGB pixel and, given some gradient mappings TBD, incorporate the amber / white / UV LEDs as necessary, for a 6-channel DMX output, for 16 of these. That's where my custom code would have to go, I assume, somewhere between the OLA OPC input and the OLA DMX output. Note that I'm only using 16 "pixels" worth of data, so performance is not essential. I have a DMXKing ultraDMX Micro. It would be nice to run this on my small Windows box, but I understand the ultraDMX Micro isn't yet supported, so I can use my Mac instead.

As a proof-of-concept I could probably just get the OPC packets sending to the DMX fixtures in 3-channel RGB mode? Then add the fancy bit to incorporate the other colors.

Thanks!

[Peter Newman]

Hi Grant,

So you've got a few options here. OLA doesn't really care about the RGB aspect of the OPC data, it's just channels/slots which it maps to DMX channels/slots, so you could do the mapping/maths within your app/in web socket land or whatever if you wanted, then just patch the first OPC output to your DMX universe and your sorted.

However doing it within the OLA end of things is also perfectly possible, just patch the OPC output to universe 1 say, your DMX output to universe 2 and have an OLA client which listens on universe 1, generates processed output and sends that to universe 2. For the client, take your pick from our supported languages:

https://www.openlighting.org/ola/apis/

If you have a search on the mailing list, a few people have done similar code (the input, process, output, maybe not the colour mapping, but there has been other discussion on that.

Regarding Windows, the Micro uses our USB Pro plugin, which currently works on serial ports in *nix, so would need some rewriting for Windows. It's not impossible, something like the FTDI library would probably do the job and there's only some fairly low-level bits which would need switching, once the port is open, then the data read/written should be the same regardless, so if you wanted to give that a go we could give you a hand with it?

[Grant Patterson]

Thanks Peter! I'd rather keep the OPC / webapp generating RGB and process within OLA, so I'll try your latter suggestion. And I'll develop on my Mac and, if I'm motivated, try to get it running on Windows.

[Peter Newman]

Fair enough, that certainly makes sense generally.

Unless you can put your LED PARs into RGB mode, you'll have to write some code (as an OLA client) to re-process the incoming OPC data to add gaps so it doesn't send RGB data on the non-RGB channels anyway. Feel free to post with any more queries about that side of it.

Have a look at this thread, I think it was the one I was thinking of and the channel mapper would make your fixtures work in RGB mode regardless, and generally the code will give a good hint as to how yours probably wants to go when adding the colour conversion (just bring your own colour conversion code):

https://groups.google.com/g/open-lighting/c/qb-FTXpRYHI

The other Windows option would be to swap to one of the other supported devices which does work on Windows, although there's obviously a cost there and they're mostly not as good IMHO.

[Grant Patterson]

I looked at that thread and the various implementations look like they have a lot of code I might not need. I have a proof-of-concept working, which "skips" the white/amber/uv channels, so input like r1,g1,b1,r2... becomes r1,g1,b1,0,0,0,r2...

All I did was add this to the end of NewDmx in the DMX512 Receive example here: http://docs.openlighting.org/ola/doc/latest/client_tutorial.html

  ola::DmxBuffer output;
  for (int i = 0; i < data.Size(); i += 3) {
    output.SetChannel(i*2, data.Get(i));
    output.SetChannel(i*2 + 1, data.Get(i + 1));
    output.SetChannel(i*2 + 2, data.Get(i + 2));
    output.SetRangeToValue(i*2 + 3, 0, 3);
  }
  std::cout << "Sending " << output.Size() << std::endl;
  client->SendDMX(2, output, ola::client::SendDMXArgs());

Am I missing something else that I need? I do see stuff about gracefully handling server shutdown in the advanced example. Also, the output buffer seems to always be 512 channels even though I'm only using 96...

[Peter Newman]

So this bit of code is a bit simpler:

https://github.com/s-light/OLA_channel_mapper_simple/blob/master/olamapper.py

But if you don't need the complications of custom mapping, you can indeed make it simpler then.

It looks like your code will work, you'll want to cap your data.Size() so you can't make a universe with more than 512 channels in.

You could also call output.Blackout() first, then you don't need the SetRangeToValue if it's only zero.

[Grant Patterson]

Yeah, could you help me understand DmxBuffer size? It seems like the size can be something other than 512 if it's set from another buffer, a string, etc., but if I'm building it up value by value it will always be 512 channels, due to blackout() setting size accordingly. Is that right? My real question is, will I gain DMX transmission efficiency by having a smaller buffer? I'd rather send 96 channels instead of 512 if I can help it, and if so, how do I achieve that?

Thanks for the continued help! I'm impressed by how simple it's been to get this up and running. Other than the segfault, olad "just works"!

[Peter Newman]

Yeah, the DMX spec only sets some timing based limits on the minimum universe size (which is around 24 slots from memory). If you device supports sending smaller frames (and OLA talks to it in a suitable way to do so which it generally will), then as long as your fixtures actually follow the spec and handle it, then yes you'd get better efficiency, i.e. a higher refresh rate.

Our DmxBuffer doesn't currently have a truncate option although it wouldn't be too hard to write. It does seem to like calling Blackout() though and setting the size to a full frame. You'd probably need to use the set and pass in the data from another buffer (or a raw array).

I'm glad you've found it simple, that's sort of the aim is the core deals with all the complicated fiddly bits, so you can just concentrate on doing unusual things with the data or connected universes in odd ways.