Is there a Linux ArtNet API for programmers?

[Nick]

I'm working on Linux and I'd like to write a program that controls lights, without getting into the low level DMX protocol stuff.

Let's say I get an ENTTEC ODE Mk2 that receives ArtNet and produces DMX.

Is there an API / command line tool or something similar that's programmable?

Something like:
MyArtNetBox = GetBoxByIP(123.123.123.123);
MyArtNetBox.SetDMX(1,255); // Set channel one to 255
MyArtNetBox.SetDMX(2,100);// Set channel two to 100
MyArtNetBox.Go(); // Fire all of the set values.

Thanks,
Nick

[Peter Newman]

You don't specify a preferred language Nick, but there are a number of options.

You can use olad to send/receive Art-Net (and lots of other protocols) and then use one of our APIs to control it:

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

We also have libartnet which is a C library which just does Art-Net:

https://www.openlighting.org/libartnet-main/

There are also some other non Open Lighting Project solutions available (e.g. Node JS) if you search for them.

[Nick]

My background is in web development so I'm most familiar with PHP/JavaScript. I'm not sure how viable it is to build something in PHP that requires hardware integration though (MIDI for controller input and libraries for DMX), but I'd prefer a language that works at a higher level (ie. no manual memory management, easy to build GUI, etc). Should run on Linux and not have any dependency on proprietary stuff or use libraries that force certain licenses. I think GTK or QT or something had some odd licensing issues. I don't remember which.

I'd rather spend time writing the console than dealing with learning a new language. Especially stuff like writing code that draws buttons and GUI elements, if I could just use HTML/CSS to do it faster.

 It would be cool if it could be done in javascript, but I don't know how to make MIDI input work through a browser, and how to make it zero latency when you hit the "go" button. Does anyone know the typical response time (in ms) of a traditional console outputting DMX directly? I would need to do some bench-marking and see if there is a preceptable difference with a round trip application. Building on a webserver could create some interesting options if the hardware issues worked.

[Glenn Meader]

1. Python has good libraries available for ArtNet, and other DMX type lighting control protocols. 

For libraries specific tomArtNet, Google:

     Python ArtNet

Of course, Python can easily use OLA as a flexible way to communicate with lighting gear using various DMX type protocols. 

There are several example open-source applications that demonstrate this - findable on github.

2. A modern browser has a MIDI API built-in. There are lots of demo JS apps available by searching. The code is not too difficult. 

The OLA project has examples of a browser talking to the OLA server (running on a Linux box, such as a Raspberry Pi) to transmit DMX. So it is fairly straightforward to make a JS app that handles MIDI and drives a DMX backend. 

[Peter Stuge]

Nick,

Nick wrote:
> I'd rather spend time writing the console than dealing with learning a new
> language. Especially stuff like writing code that draws buttons and GUI
> elements, if I could just use HTML/CSS to do it faster.

What kind of precision and/or repeatability do you want your console to have?

What kind of framerate would you like to achieve for something like a fade?

How would you like to implement frame calculation/rendering?

> It would be cool if it could be done in javascript, but I don't know how
> to make MIDI input work through a browser, and how to make it zero latency
> when you hit the "go" button.

Nothing has zero latency, but latency, and jitter in the latency, will be
(visibly) awful if rendering and/or DMX output runs on a general purpose
kernel.

Bare-metal (so no kernel at all) or a realtime kernel are some
possibilities to get the "right" result.

> Does anyone know the typical response time (in ms) of a traditional
> console outputting DMX directly?

I'd expect single-digit ms at most, which isn't (reliably+repeatably)
achievable without dedicated processing hardware.

> I would need to do some bench-marking and see if there is a preceptable
> difference with a round trip application.

If you render say a fade in a browser the result will highly like look
awful right away. If you render on the webserver using say PHP or Node
then there will not neccessarily be immediately visible problems, but
as you increase load on that webserver (more complex rendering, more
network traffic) jitter is highly likely to become a problem.

> Building on a webserver could create some interesting options if the
> hardware issues worked.

You've identified the major problem already - and it's not very easy to
overcome.

If you want to create a smooth fade then you need to render frames
without jitter, and if you drive all 512 channels in a universe you
can achieve at most a 44 Hz framerate, meaning 22 ms per frame.

For a general purpose kernel (like Linux) it is already challenging
to achieve jitter that's insignificant given that requirement for 22 ms
frame updates.

In-kernel I'd say it's fairly doable.

In a minimal userland process it's already uncertain.

Adding massively thick web technology layers on top of that doesn't help. :\


Kind regards

//Peter

[E.S. Rosenberg]

Console response time cannot be less then a single frame time since whatever frame is being put on the line will continue to be written and only the next frame will change, the only scenario I can imagine in which a frame is going out immediately with a button push is either the push happening exactly in between frames or the console being set to only broadcast when a change happens or the expiry timer will happen (DMX requires at least 1 frame per second).

For full frames in RDM the full frame to frame time is roughly 23ms as Peter already pointed out.

I disagree with Peter about the Linux kernel being able to keep up, with the right hardware and a real time mode it should be possible to make the timings.

That said it also depends on the device you use to output, a USB bus which is a polling technology is not great for this and as Peter also says a webstack will add significant latency.

HTH,

Eli

Op ma 14 sep. 2020 om 16:52 schreef Peter Stuge <pe...@stuge.se>:

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en
---
You received this message because you are subscribed to the Google Groups "open-lighting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-lightin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/20200914135211.10787.qmail%40stuge.se.