From dd91621ccee033550312683293b5bf40c3599053 Mon Sep 17 00:00:00 2001 From: cbdev Date: Sun, 23 Feb 2020 18:20:12 +0100 Subject: Implement OpenPixelControl output --- backends/openpixelcontrol.md | 49 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 backends/openpixelcontrol.md (limited to 'backends/openpixelcontrol.md') diff --git a/backends/openpixelcontrol.md b/backends/openpixelcontrol.md new file mode 100644 index 0000000..ce60278 --- /dev/null +++ b/backends/openpixelcontrol.md @@ -0,0 +1,49 @@ +### The `openpixelcontrol` backend + +This backend provides read-write access to the TCP-based OpenPixelControl protocol, +used for controlling intelligent RGB led strips. + +This backend can both control a remote OpenPixelControl server as well as receive data +from OpenPixelControl clients. + +#### Global configuration + +This backend does not take any global configuration. + +#### Instance configuration + +| Option | Example value | Default value | Description | +|---------------|-----------------------|-----------------------|-----------------------| +| `destination` | `10.11.12.1 9001` | none | Destination for output data. Setting this option enables the instance for output | +| `listen` | `10.11.12.2 9002` | none | Local address to wait for client connections on. Setting this enables the instance for input | +| `mode` | `16bit` | `8bit` | RGB channel resolution | + +#### Channel specification + +Each instance can control up to 255 strips of RGB LED lights. The OpenPixelControl specification +confusingly calls these strips "channels". + +Strip `0` acts as a "broadcast" strip, setting values on all other strips at once. +Consequently, components on strip 0 can only be mapped as output channels to a destination +(setting components on all strips there), not as input channels. When such messages are received from +a client, the corresponding mapped component channels on all strips will receive events. + +Every single component of any LED on any string can be mapped as an individual MIDIMonster channel. +The components are laid out as sequences of Red - Green - Blue value triplets. + +Channels can be specified by their sequential index (one-based). + +Example mapping (data from Strip 2 LED 66's green component is mapped to the blue component of LED 2 on strip 1): +``` +strip1.channel6 < strip2.channel200 +``` + +Additionally, channels may be referred to by their color component and LED index: +``` +strip1.blue2 < strip2.green66 +``` + +#### Known bugs / problems + +If the connection is lost, it is currently not reestablished and may cause exit the MIDIMonster entirely. +Thisi behaviour may be changed in future releases. -- cgit v1.2.3 From e1fcd4d11cfdbad54470b2cce98d8b749464ec00 Mon Sep 17 00:00:00 2001 From: cbdev Date: Thu, 27 Feb 2020 00:33:22 +0100 Subject: Implement OpenPixelControl server mode (8bit) --- backends/openpixelcontrol.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'backends/openpixelcontrol.md') diff --git a/backends/openpixelcontrol.md b/backends/openpixelcontrol.md index ce60278..6dd38bc 100644 --- a/backends/openpixelcontrol.md +++ b/backends/openpixelcontrol.md @@ -45,5 +45,10 @@ strip1.blue2 < strip2.green66 #### Known bugs / problems -If the connection is lost, it is currently not reestablished and may cause exit the MIDIMonster entirely. -Thisi behaviour may be changed in future releases. +If the connection is lost, it is currently not reestablished and may cause the MIDIMonster to exit entirely. +This behaviour may be changed in future releases. + +While acting as an OpenPixelControl server, the backend allows multiple clients to connect. +This may lead to confusing data output when multiple clients are trying to control the same strip. + +16 bit server mode is not implemented yet. This will be fixed in a future release. -- cgit v1.2.3 From 454e757f740b74d714e9fa47bfa4954cb30e67ba Mon Sep 17 00:00:00 2001 From: cbdev Date: Fri, 28 Feb 2020 21:10:45 +0100 Subject: Implement openpixelcontrol 16bit server mode --- backends/openpixelcontrol.md | 2 -- 1 file changed, 2 deletions(-) (limited to 'backends/openpixelcontrol.md') diff --git a/backends/openpixelcontrol.md b/backends/openpixelcontrol.md index 6dd38bc..5a8686f 100644 --- a/backends/openpixelcontrol.md +++ b/backends/openpixelcontrol.md @@ -50,5 +50,3 @@ This behaviour may be changed in future releases. While acting as an OpenPixelControl server, the backend allows multiple clients to connect. This may lead to confusing data output when multiple clients are trying to control the same strip. - -16 bit server mode is not implemented yet. This will be fixed in a future release. -- cgit v1.2.3 From 1b3f7610d47ba5464e7aa2e16b5b1a27b7d0f5a3 Mon Sep 17 00:00:00 2001 From: cbdev Date: Fri, 6 Mar 2020 23:46:43 +0100 Subject: Implement openpixelcontrol broadcast (strip 0) input --- backends/openpixelcontrol.md | 3 +++ 1 file changed, 3 insertions(+) (limited to 'backends/openpixelcontrol.md') diff --git a/backends/openpixelcontrol.md b/backends/openpixelcontrol.md index 5a8686f..d09d412 100644 --- a/backends/openpixelcontrol.md +++ b/backends/openpixelcontrol.md @@ -50,3 +50,6 @@ This behaviour may be changed in future releases. While acting as an OpenPixelControl server, the backend allows multiple clients to connect. This may lead to confusing data output when multiple clients are trying to control the same strip. + +When acting as a 16bit OpenPixelControl server, input on the broadcast strip (strip 0) may cause erratic +value events on a few channels, especially with longer strips and inputs. -- cgit v1.2.3