Discussion: Architectural Considerations for Live Band Lighting Controller

Publishing this as more of a discussion item for @MattIPv4 to consider and perhaps comment on rather than an actual enhancement request appropriate for this library. A lot of what I've run into in my work might end up being breaking changes if actually tackled as an enhancement to this library. I'm considering branching off of this project to do some of these enhancements but before doing so wanted to outline my thinking.

ℹ️ Background: I'm attempting to use PyDMXControl as the underlying library of a Midi controllable show controller for live bands that speaks DMX and will control multiple fixtures based on preprogrammed patterns. In doing so, I've come across some edge cases that possibly rub up against some core design assumptions of PyDMXControl.

Clarify and Align speed, offset, and delay parameters

I noticed that speed is in ms while offset and delay are in percentage integers (i.e. 50 = 50%). Took me a while to work out the math to figure out what was going on here. It might be helpful to those using this in precise timing applications to keep these consistent as ms.

Proposed Sequence Effect Class

I had the need to be able to kick off a string of animations targeted towards a group of fixtures but then also loopback to a specific step. Consider the example of a scene change that bursts the lights to full white then begins cycling a chase-like pattern through 4-5 steps.

To implement this, I created a new Sequence Effect class that allows one to pass in a list of Fixture operations that you'd like to perform at certain times in sequence with ability to loopback to a specific index and define the step timing. Steps are passed in a dict of tuples where the key is the ms value at which to perform the animation and the tuple contains the Fixture operation, and arguments. You can also offset by step instead of percentage, and define a loopback point in that list of steps.

The following will run all lights Pink, Blue, Red, Warm, Green, then cycle Red, Warm, Green in a loop. Because offset_index is False, all lights are in sync. If offset_index was True, then the first light in the all_lights list would start on pink, the second would start on Blue, the third on Red, etc.

all_alights = dmx.get_fixtures_by_name_include('Band')
Sequence.group_apply(all_alights, offset_by_index=False, loopback_index=2, steps={
    0: [["color",Colors.Pink,0]],
    1000: [["color",Colors.Blue,500]],
    2000: [["color",Colors.Red,500]],
    3000: [["color",Colors.Warm,500]],
    4000: [["color",Colors.Green,500]]
})

Proposed Ability to Cancel Fixture Animations

Considering in my code I now have this Sequence class that can apply animations across fixtures, if I want to enable a new Sequence, I need the ability to not only remove the Effect from the callbacks (e.g. my specific Sequence class), but also the animation calls that were attached to the fixtures. I encountered this when applying this use case:

Let's say I have a Sequence that slowly fades out all lights over a period of 8000ms followed by bringing those lights up to half dim in 5000ms. (good for end of song and then bringing house lights backup before next song 😎)

Before that first fade out is completed, let's say my Light Controller responds to a Midi input 4000ms into that Sequence that requests a new sequence be executed instead. To handle this I can remove the callback that refers to my Sequence which would prevent the second half dim 5000ms call from being executed.

However, the previously executed call to the Fixtures that is still running "color" or "dim" over the initial 8000ms is running and cannot be stopped.

Removing all callbacks at the controller level is a no-go because the __send function that transmits values to DMX is part of that group.

Still considering the best way to handle this. I've had success clearing all callbacks and then adding back the__send callback, but it seems hackish. Still pondering and experimenting. 🤔

dmx.clear_all_effects()
dmx.ticker.clear_callbacks()
dmx.ticker.add_callback(dmx._TransmittingController__send, 0)

At any rate, you can probably see that my use is running into some possible design assumptions. I'd be happy to consider thoughts and opinions on this. I would love to contribute to this project and its functionality rather than creating a Frankensteined branch.

Thanks for listening.

No se especifican archivos ni pruebas. Empieza revisando las rutas de efectos y callbacks a las que hacen referencia dmx.clear_all_effects(), dmx.ticker.clear_callbacks(), dmx.ticker.add_callback() y el callback privado __send. Done no puede definirse hasta que el maintainer elija entre la alineación de parámetros, los efectos de Sequence y la cancelación de animaciones.