Opened 10 years ago
#355 new task
Request for new stream directions *_BIDIR
Reported by: | ph3-der-loewe | Owned by: | |
---|---|---|---|
Priority: | medium | Milestone: | |
Component: | RoarAudio Protocol | Version: | current |
Keywords: | Cc: | stephanj | |
Architecture: | Compiler: | ||
Difficulty: | Kernel: | ||
Operating System: | Parent Tickets: | ||
Patch attached: | no | Protocol: | RoarAudio |
Sound driver: | Topic: | New feature |
Description
Overview
There should be some more bidirectional stream directions:
This is a list of IDs that follow the normal semantics:
- MIDI_BIDIR
- LIGHT_BIDIR
- COMPLEX_BIDIR
Those are a bit more complex but one should already allocate an ID for them so those BIDIR IDs are in a single block and there doesn't need to be that much updates on the frameworks defining constants for them:
- RAW_BIDIR
- RDTCS_BIDIR
MIDI_BIDIR
This should be a simple combination of MIDI_IN and MIDI_OUT. This can be useful for example with detached breakout boxes.
LIGHT_BIDIR
This is very interesting combination of LIGHT_IN and LIGHT_OUT. It is very useful when used with RoarDMX codec to let user interfaces update the state but get back all updates so they can share the the universe with multiple other sources.
COMPLEX_BIDIR
This will allow the complex subsystem handle bidirectional streams like LIGHT_BIDIR (see above). The type of data running in both direction will be subject to the used sub-channels as well as the control logic.
RAW_BIDIR
This will be useful for bidirection communication of any kind of pass-thru data. Exact meaning and how this will interact with other streams need to be defined in a later application. This application only requests to reserve an ID.
RDTCS_BIDIR
This may be useful in some very exotic use cases like injecting data into the RDTCS while monitoring the updates. Exact meaning and how this will interact with other streams need to be defined in a later application. This application only requests to reserve an ID.