cbdevnet / midimonster

Multi-protocol control & translation software (ArtNet, MIDI, OSC, sACN, ...)
https://midimonster.net/
BSD 2-Clause "Simplified" License
506 stars 50 forks source link

Channel mapping priority #89

Open Spacelord09 opened 3 years ago

Spacelord09 commented 3 years ago

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 or prio=10 in this case prio=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 xms another defined one will not be executed.

I hope you got my point.

cbdevnet commented 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).