Bugtracker DMXControl 3

Wieso brauchen wir das nochmal? Die aktuelle Lösung mit Selektion und Group Handling ist doch sehr flexibel...

Folgendes Szenario:
Du hast diverse LED Scheinwerfer
- 3 linke Wand
- 3 rechte Wand
- 6 Mitte

Du willst jetzt, dass die 3 Geräte an der Wand zu einem zusammengefasst werden und ein Fanning auf die "Mastergruppe" ausgeführt wird.
Dazu müsste für die Untergruppen aber der Modus des Group Handlings angepasst werden können.

@Arne, weil wenn du das als Gruppe haben willst, dann is das halt so ;)
es ist dann halt nur ein Klick um die "GruppenGruppe" zu selektieren.
Und das würde dann auch per InputAssignment leichter gehen.
Und du Hättest für die "GruppenGruppe" auch einen Groupmaster ;)

Ich finds halt auch doof, das da ein Rigel davor ist, solln die User(und ich) doch machen ^^

Also intern existieren schon "Gruppen in Gruppen". Daher wäre der Umbau das zu erlauben relativ einfach. Ich würde aber vorschlagen, das zu begrenzen:

1. Keine Rekursionen, die sind schlecht
2. Eventuell nur 1 Ebene? Oder wollen wir das beliebig lassen?

Zu 1. Ok, sollte passen
Zu 2. Warum sollte man das einschränken? Also was ist da der Hintergedanke? Aktuell sehe ich da keine Notwendigkeit dazu (liegt aber auch daran, dass ich da aktuell keine Argumente dagegen gefunden habe)

Wie darf man den Punkt 1 verstehen? Was meinst du damit? Ich kann den Begriff in diesem Zusammenhang gerade nicht zuordnen.

Wie wird ein Fanning behandelt und ausgegeben, welches ich auf die obere Gruppe "schmeiße"?

Rekursion bedeutet hier, dass du die selbe Gruppe wieder innen rein packst. Sprich Gruppe 1 ist in Gruppe 1 enthalten. Geht auch mit mehreren Gruppen. Z.B. enthält Gruppe 1 die Gruppe 2. Nun darf die Gruppe 2 nicht mehr die Gruppe 1 enthalten, weil das sonst immer hin und her geht.

Okay. Das macht dann Sinn, dass dies nicht erlaubt wird. Danke für die Erläuterung.

1. ok,
2. ich würd es erstmal ohne limit testen wollen, oder halt ein limit von 10 ebenen, und dann probieren wir mal

QRM21.3

• Im PE wird eine zusätzliche Spalte eingefügt, die die Anzahl der Untergruppen anzeigt.
• Gruppen, welchen Untergruppen zugeordnet sind, erhalten ein eigenen Icon und werden hierdurch entsprechend hervorgehoben.

Ich finde es im Augenblick irgendwie noch etwas inkonsistent mit den Gruppen in Gruppen.
Die Darstellung im PE ist gut so, aber im Handling kommen noch Fragen bei mir. Ich finde eine Gruppe in einer Gruppe sollte sich als ein Device verhalten, unabhängig vom Group Handling. Ein Beispiel: Ich möchte ein architektonisches Objekt beleuchten, dieses hat verschieden große Säulen. Für einige reicht ein Device, für andere sind es mehrere. Also erstelle ich für die größeren Säulen Gruppen. Anschließend erzeuge ich eine Master-Gruppe mit den einzelnen Geräten und den Gruppen. Wenn in nun die Säulen nun zB alternierend fannen möchte geht dies nicht. Lasse ich das Group-Handling auf "Concat Group" wird das Fanning auch innerhalb der "Untergruppe" fortgesetzt, stelle ich es um auf "Group is Device" werden zwar die Gruppen richtig angesprochen, allerdings werden nun auch alle einzelnen Devices in der Mastergruppe als ein Gerät angesprochen.
Man kann das ganze lösen indem man auch für die einzelnen Scheinwerfer Gruppen erstellt, dann nur mit einem Device, aber ich bin mir aber nicht sicher ob das für alle Nutzer der intuitive Weg ist. Ich persönlich würde bei Gruppen in Gruppen erwarten dass die Untergruppe immer als ein Device reagiert.