Open Spacelord09 opened 3 years ago
I'm not entirely sure I understand how this is meant. Currently, all events are received, translated and transmitted again as soon as they are received. There is no buffering. The only way a priority might be reasonably applied in the current structure is when two events with the same target channel arrive at the exact same moment in time (actually, in the same core iteration). This is pretty rare.
The way I understand this, introducing a priority option without also introducing buffering (ie, artificial slowdowns of some events) would lead to behaviour that is hard to explain to people. It would look like the "priority" they set is being ignored because the events did not arrive in the same core iteration and thus the priority was not applied.
Minor addendum, some backends (sACN and ArtNet) actually do have internal buffering (to satifsy output timing limitations). However, the buffer used there is basically a LTP (latest takes precedence) buffer, as that is conceptually what all other backends would do as well (and it is the easiest to implement).
Currently the Midimonster is event based which means that every action is executet at an event. For more complex configs, a mapping priority would make sense to execute more important translations faster and possibly also to get ahead of other mappings. A config syntax for that can be like
prio=1
orprio=10
in this caseprio=10 is executet bevor prio=1
.To extend this further we could make on or multiple mapping dependent to others. so for example if one mapping arrived before
x
ms another defined one will not be executed.I hope you got my point.