Hi barnone,
as far as I can remember you mentioned that you are interested in helping out with OSC support. If you find time just say so, the OSC fans would be thankful I guess :)
Just had some first thoughts into that direction. As almost all vital information is exposed via atoms now perhaps it would make sense to have a deeper look into the brpc utility and look how this is collecting a list of all available agents and retrieves current values of all their atoms (dump). If we would have a comparable OSC input agent this could be used to expose a big part of EigenD configuration options via OSC by just adding one (presumably not "really" trivial) introspecting and delegating agent.
This would work for simple data types - essentially all things that you usually set via Belcanto/talkers, so we wouldn't even need "auto-plumbing", as changing these config-atoms usually does not need too high bandwidth the interpreter could be used.
For writing actual data streams we'd presumably still need specialized OSC agents - finding out what data format is expected inside blobs or vectors is already difficult for humans sometimes :)
But at least for the midi illuminator that wouldn't even be neccessary I think.
Here the currently planned configuration options exposed via atoms for the
alpha/tau/pico midi light controller. All of those should be OSC-automatable with the "generic" OSC-input approach (I think?)
(Renamed the agents to only use existing belcanto words to avoid frequent merge conflicts in the belcanto language file every time Eigenlabs invents a new word exactly at the spot where I placed "illuminator" ;) ):
* current layout [1-20, default: 1]:
number of layout that is currently used for note to key mapping
* enable: [True/False, default: True]:
if set to False all illuminator controlled lights are disabled (e.g. to use menus etc.)
* green/orange/red lights
(status flags that can be used to disable a feature for a certain color - e.g. to concentrate on one hand via midi, disable certain static helper lights to reduce confusion etc.; one group exists for each color)
- enable direct keys [True/False, default: True]:
show green/orange/red lights for keys as mapped in the "keys" group
- enable direct notes [True/False, default: True]:
show green/orange/red lights for all keys that are mapped to the notes in the "notes" group
- enable midi [True/False, default: True]:
show green/orange/red for all keys that are mapped to the notes that are currently played via midi
* key to note maps
(group of groups of keys [note number, default: chromatic vertical 4xn layout (default Eigenharp layout)] These layouts determine the key->note (or note->keys) mapping that is used to determine which keys are lit by incoming midi notes or notes set in the "notes" group
- current layout
(this layout is always a copy of the layout indicated by the "current layout" atom - this is helpful so you can maintain all layouts in one Stage tab instead of needing a tab per layout)
- key 1
....
- key 120(alpha)/72(tau)/18(pico)
- layout 1
...
- layout n
* keys [disabled/green/orange/red, default: disabled]
(group of "direct keys" which can be used to statically assign colors to keys independent of note pitch
- key 1
...
- key 120(alpha)/72(tau)/18(pico)
* midi channels
(defines which colors should be used to visualize which channels [disabled/green/orange/red, default:disabled])
- color for channel 1
...
- color for channel 16
* notes [disabled/green/orange/red, default: disabled]
(list of all midi notes. This can be used to statically visualize certain notes - e.g. to visualize tonics/IV/V etc.)
- 1: c0
...
- 128: g10
* priorities
(in the case that midi/direct key/direct note all want to light up the same key you need to have a priority [1-4; default: midi > direct notes > direct keys]. Prio 1 wins):
- direct keys prio
- direct notes prio
- midi prio
* transpose [-120;120; default: 0]
number of semitones that the layout should be transposed (has an impact on the visualization of midi notes and direct notes but not on direct keys)
Greetings,
NothanUmber
UK
