Vision

[LRahlff]

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

[Doralitze]

Which „program“ are we talking about now? Fish? The use case should be fairly straight forward. Or are we talking about the event subsystem?

[LRahlff]

i meant the fish, or more directly an example of a scene (generated by the ui) (ok, i thought it is a more general topic, so i placed it here)

[Doralitze]

In general, a scene is just a collection of filters, whose execution determine the output that should be send to fish. Every filter has its own state, consums a predefined set of inputs and provides outputs. It is possible for a filter to receive or send GUI update notifications. Besides that it can store or load values from global state. Finally, a filter may listen to events and perform actions on them.

There is only up to one scene running at a time. The X-Touch provides human input to scenes. Events are inserted by various sources which are configurable.

[LRahlff]

i think i undestand this part (but not the eventsystem for all), but i want to ask what do you think should be possible later, and want to share what my idea is, regarding handling multiple cues/transitions/executors or even live editing and fixtures in different groups (addressed through different groups with different values).

[Doralitze]

Well in that case: if you have ideas regarding these features, just describe them in issues and start implementing them. The things I'm currently working at are focused on the editor as we're lacking there. In the future, I'd looking into pixel mapping and shader execution for fish.

Personally, I wouldn't focus on changing the filter layout of a running scene. My reason: As we're using a linear allocator in order to garuntee continious allocation for cache locality, this will be very complicated. Furthermore it can easily mimiced with the update mechanism using the global state system. But if you'd like to work on that: feel free to do so.

[Doralitze]

Based on our talk we concluded the following requirements:

• Mixer nodes need an option to do priority based mixing
• Multi input mixer need to represent this option as well
• Issue 168 in the project editor needs to be implemented
• Sequencer Config Widget needs to be implemented
• Event Configuration Widget needs to be implemented