an API for xlights

[ptone]

The area where xlights is by far strongest, and most mature, is in its abstraction of the network from the channel.  Currently, xlights is poised to be THE rosetta stone of DIY lighting.  It would be my opinion that xlights should focus on being the best at that first, and that sequencer's etc be different apps.  For example, the sequencer project that csf is talking about, could be an application like prancer, that does not talk to hardware at all.  For this sequencer, or prancer, or my project to talk to xlights - it needs an API that can be loaded/accessed by these other apps.

This would perhaps best be done as a daemon with sockets.  Bonus would be if it used OSC, then it could potentially tap into that ecosystem. (OLA is a good model here)

Cas was just asking for basically this in the prancer forum.

csf, basically you would end up doing some of this in writing your sequencer.  But instead of it being a "private" API connection between your sequencer and the network driving plugins, you would spend a little extra to clean up and abstract out that API.

-Preston

[csf]

I realized that in REV 43 that xlights went from dynamic to static serial library.

You are not allowed to view links. Register or Login

would you want a dynamic Library, or should I continue typing up instructions for using it static? 

[ptone]

For what I have in mind - I think it is less about whether it is static or dynamic, but more important that it be configured to be a shared library.

You are not allowed to view links. Register or Login

In general these are dynamic.

on Unix systems these typically get installed in /usr/local/lib/   with documented .h files in /usr/local/include

Also the idea would be to provide an API that offers different levels of usage of the xlights goodness.

For example you might choose to read the network definition file in the standard xlights location - or just create networks and channels on the fly.

Again - I don't know a ton about how one crafts and exposes such an API in C - but I know a bit about how to access and bind to it from other languages.  You might statically link in the serial part - but then have the entire xlights lib exposing the features of xlights_out.cpp in a dylib.

-Preston