Mission-DMX / Mission-DMX/Docs
Vision
@Doralitze is already working on this.
Since Mar 3, 2025.
- Dominant language
- SCSS
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
i just want to ask you how is your idea of the program, how to use it, maybe how to program it and in first case how the backend works?
so i created a diagram what my idea is regarding the backend. My motivation got a little bit lost, because i dont see how we could privide some use cases.
i just added the left third part, but for me the right part is important. (maybe we dont need the groups, cause we could connect directly all outputs from anything targeting a group to its devices). but i think we should think more about running cuelists/transitions/executors with the same destination at the same time.
I m sorry for the bad uml design, i could not figure out how to position the ports.
Source of the picture, just in case you want to change something
@startuml
left to right direction
skinparam componentStyle rectangle
component group1 {
portin gr1_val
portout gr1_values
}
component group2 {
portin gr2_val
portout gr2_values
}
component dev1 {
component dev1_mixer_Red {
portin inR1_val
portin inR1_prio
portin inR1_mixscale
portin inR2_val
portin inR2_prio
portin inR2_mixscale
portout outR
}
note right : calculates the value according to highest priority \n(and if more than one is available, they get mixed \naccording to their mixscale (and maybe another mixtype))
note bottom : so every value needs a mixscale and priority
component dev1_real {
portin dev1_rR
portin dev1_rG
portin dev1_rB
portin dev1_rposX
portin dev1_rposY
}
portin dev1R
portin dev1G
portin dev1B
portin dev1posX
portin dev1posY
}
component dev2 {
portin dev2_values
}
component dev3 {
portin dev3_values
}
component value_from_device {
portout deviceR
}
note right : value from one device of the last round
component any_fader{
portout any_fader_out
}
note right : fader could be artnet or midi etc.
component magic_stuff{
portin real_fader
portin current_value
portin (maybe reset)
portout fader_adjusted
}
note right : (if you dont have a motorfader one could \nprevent changing the value if it did \nnot match the actual one)
any_fader_out --> real_fader
deviceR --> current_value
component x-touch_fader{
portin fader_dest
portout xtouch_fader_out
}
deviceR --> fader_dest
component programmer {
portin prog_fader_in1
portin prog_fader_in2
portout prog_values
portout prog_devices
}
fader_adjusted --> prog_fader_in1
xtouch_fader_out --> prog_fader_in2
note right : maybe we could have multiple programmer \nnodes for adjusting values for different \ngroups simultaneously
component programmer_dev1_selector {
portin dev1_prog_value
portin dev1_prog_devices
portout dev1_prog_out
}
note right : dev1 in devices_list ? dev1_prog_value :\n defaultvalue (0/Black) for this datatype
prog_values --> dev1_prog_value
prog_devices --> dev1_prog_devices
dev1_prog_out --> dev1R
prog_values --> gr2_val
prog_values --> gr1_val
prog_values --> dev3_values
prog_values --> dev2_values
outR --> dev1_rR
dev1R --> inR1_val
dev1R --> inR1_prio
dev1R --> inR1_mixscale
dev1R --> inR2_val
dev1R --> inR2_prio
dev1R --> inR2_mixscale
gr1_values --> dev1R
gr1_values --> dev2_values
gr2_values --> dev3_values
gr2_values --> gr1_val
component transition1 {
portout tr1_value_dev1
portout tr1_value_dev3
portout tr1_value_gr1
}
tr1_value_dev1 --> dev1R
tr1_value_dev3 --> dev3_values
tr1_value_gr1 --> gr1_val
component cuelist1 {
portout tr2_value_dev1
portout tr2_value_gr1
portout tr2_value_gr2
}
tr2_value_dev1 --> dev1R
tr2_value_gr1 --> gr1_val
tr2_value_gr2 --> gr2_val
@enduml
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.