Feature request: DMX to stdout

[kengruven]

I had trouble using the 'official' APIs, so for the time being, I'm using ola_streaming_client to send DMX data from my program to OLA. It's simple and it works fine.

I'd also like to do the opposite, i.e., read the current DMX state from OLA. Unless I'm missing it, OLA doesn't quite have the input version of this functionality:

• ola_streaming_client is output-only
• ola_set_dmx is like a one-shot variant of the former (and I'm not sure why it even exists, since its functionality is a literal subset of ola_streaming_client)
• ola_recorder records changes to DMX, and outputs them in an almost identical format to what ola_streaming_client uses for output (nice!), but it only supports writing to the filesystem, so you wouldn't want to leave it open and running for an extended period of time, and it doesn't emit any data until there's a change
• ola_recv_dmx.py (not part of the distribution, perhaps because it's an "example", but the C++ command-line programs are "examples", too -- ?) uses the Python API to output changes to stdout, but it also doesn't send the initial state until a change occurs, and it uses a Python-specific format which isn't compatible with any other OLA tools

It would be great if there were a program (or new mode for one of the above programs) which read the current DMX state from OLA and wrote it to stdout, and emitted a new line whenever it changed.

Is this a feature which OLA would be willing to merge? Is there a preference for where/how it's added? I can't tell if there's an over-arching design of the command-line interfaces.

[peternewman]

I had trouble using the 'official' APIs, so for the time being, I'm using ola_streaming_client to send DMX data from my program to OLA. It's simple and it works fine.

If you want to expand on that at some point (which programming language, what sort of problems), we can try and help with that.

I'd also like to do the opposite, i.e., read the current DMX state from OLA. Unless I'm missing it, OLA doesn't quite have the input version of this functionality:

* `ola_streaming_client` is output-only

* `ola_set_dmx` is like a one-shot variant of the former (and I'm not sure why it even exists, since its functionality is a literal subset of `ola_streaming_client`)

Technically it's the other way round (in terms of API, if not functionality), the former is using our more complex/versatile C++ client, the latter a simpler client that can only send DMX data:
http://docs.openlighting.org/ola/doc/latest/dmx_cpp_client_tutorial.html

* `ola_recorder` records changes to DMX, and outputs them in an almost identical format to what `ola_streaming_client` uses for output (nice!), but it only supports writing to the filesystem, so you wouldn't want to leave it open and running for an extended period of time, and it doesn't emit any data until there's a change

I'd never considered that they weren't identical/compatible, we should consider that too (or do you just mean the timing data). We could also possibly consider modifications for ola_recorder to be able to read/write from STDIN/OUT, although there may be some edge cases there.

* `ola_recv_dmx.py` (not part of the distribution, perhaps because it's an "example", but the C++ command-line programs are "examples", too -- ?)

I've now raised this lack of distribution as #1916 as I'd spotted it before but don't seem to have made an issue previously.

uses the Python API to output changes to stdout, but it also doesn't send the initial state until a change occurs, and it uses a Python-specific format which isn't compatible with any other OLA tools

It would be great if there were a program (or new mode for one of the above programs) which read the current DMX state from OLA and wrote it to stdout, and emitted a new line whenever it changed.

Is this a feature which OLA would be willing to merge? Is there a preference for where/how it's added? I can't tell if there's an over-arching design of the command-line interfaces.

Yeah I think that would be fine to merge in theory. A few things to note, the example programs in either language are 50/50 between the simplest example of using a particular API in a vaguely usable way (e.g. ola_set_dmx and the C++ RDM tools) and something more powerful and useful that uses OLAs infrastructure and lets you do some tests (e.g. ola_recorder, some of the Python tools). So they sort of fulfil two purposes, they're both a literal example/something someone can hack on, but also a simple tool to test the olad core (e.g. I can use ola_set_dmx to interact with it, or a dongle, without the complexity of say our web UI in the way).

From the code perspective, the easiest thing might be to just add an option to the Python examples to offer a different output format (e.g. one matching ola_streaming_client (with the universe) or ola_set_dmx). You could also add singular ola_recv_dmx/ola_fetch_dmx examples.

The other subtlety and why a lot don't send something until there is a change, is that there are two distinct API commands:

• Get the current data now, returns immediately, data will be stale, from some unknown time before, a one shot request - e.g. https://github.com/OpenLightingProject/ola/blob/master/python/examples/ola_fetch_dmx.py
• Subscribe to a universe and give me all future frames, no immediate data, never returns, data always current, but not immediate - e.g. https://github.com/OpenLightingProject/ola/blob/master/python/examples/ola_recv_dmx.py

If you care about things like fades, then getting the immediate value, and then every sent frame, that first one might have a different time delta to the others, because you've offset it, plus the other API call.

Probably the best bet is to have a look at some of our APIs and what function you need and then stick a suggestion in here maybe rather than just immediately going to coding given the options. But matching basic ones that mirror the Python standalone ones would certainly be accepted (but won't necessarily do everything you need).

[kengruven]

I may retract this request, as I've gotten an in-process API working. Still, there is some inconsistency here in functionality and formats, so it might be nice to improve the situation.

I had trouble using the 'official' APIs, so for the time being, I'm using ola_streaming_client to send DMX data from my program to OLA. It's simple and it works fine.

If you want to expand on that at some point (which programming language, what sort of problems), we can try and help with that.

I can write a lengthier comment if you want, but the short version is: the language I'm using has 2 protobuf libraries, and OLA was running into bugs (report number one, in each of them!). I did eventually get this to work, but the barrier to entry was much higher than I expected.

The great thing about Unix-style commands (command line, lines of text) is that they're super easy to get started with. Debugging protobuf implementations (especially if you've never used them before) is all the way on the other end of the scale.

I'd never considered that they weren't identical/compatible, we should consider that too (or do you just mean the timing data). We could also possibly consider modifications for ola_recorder to be able to read/write from STDIN/OUT, although there may be some edge cases there.

The timing data, and the header line (IIRC). It's not difficult to convert between them, but it would be great if they were compatible by default.

Yeah I think that would be fine to merge in theory. A few things to note, the example programs in either language are 50/50 between the simplest example of using a particular API in a vaguely usable way (e.g. ola_set_dmx and the C++ RDM tools) and something more powerful and useful that uses OLAs infrastructure and lets you do some tests (e.g. ola_recorder, some of the Python tools). So they sort of fulfil two purposes, they're both a literal example/something someone can hack on, but also a simple tool to test the olad core (e.g. I can use ola_set_dmx to interact with it, or a dongle, without the complexity of say our web UI in the way).

Agreed -- and maybe this is turning into a larger task of classifying/improving/segregating OFL's "industrial-strength tools" from "simplest possible use case demos".

The other subtlety and why a lot don't send something until there is a change, is that there are two distinct API commands:

Right, but wearing the hat I am (someone who wants to see a best-effort current state of the DMX bus), this distinction is not useful. It's an implementation detail to be worked around. Then again, it may be fair to say that the command line tools simply wrap the existing APIs, and I shouldn't expect them to be usable as a high-level interface.

[shenghaoyang]

Out of curiosity, did you try pointing the recorder to use /dev/stdout? IIRC the recorder shouldn't be doing any seeking etc. So it should work just fine with a pipe.

[kengruven]

You're right: /dev/stdout does work. I don't know why I didn't think of that before.