Bugtracker DMXControl 3

  • Status geschlossen
  • Prozent erledigt
    100%
  • Aufgabentyp Wunsch / Idee
  • Kategorie GUI & Server → InputAssignment
  • zuständig
    Soon5
  • Betriebssystem All
  • Schweregrad niedrig
  • betrifft Version 3.2 Beta x
  • fällig in Version unbestimmt
  • fällig am unbestimmt
  • Stimmen
  • versteckt
gehört zu Projekt: DMXControl 3
angelegt von LightningBrothers - 13.03.2019
zuletzt bearbeitet von Soon5 - 27.07.2019

FS#3466 - Nachträgliches ändern von Softdesk-Controls ebenfalls zulassen

Auf Gründen der Konsistenz und der einfacheren Bedienung wäre zu Überlegen, ob man die nachträgliche Änderung der Zuordnung von Softdesk-Controls im Graphen ebenfalls zulässt und das Node- / Klassenkonzept auf diese ausweitet. Hierbei könnte aber durchaus in Betracht gezogen werden, dass dies nur typengleich erfolgt - sprich ein Slider wird durch einen anderen Slider ersetzt oder ein Button durch einen anderen Button.

Sofern möglich kann dieser Wunsch auch auf MIDI-Controller und Tastatur ausgeweitet werden.

geschlossen von  Soon5
27.07.2019 05:06
Grund für das Schließen:  Implementiert
Project Manager
Soon5 schrieb am 13.03.2019 18:40

Ja. Das ist nur ein größerer Umbau. Wie du gemerkt hast, sind es die "UI" Seitigen Elemente, die noch nicht umgebaut sind. Das kommt irgendwann mal.

nutzer99 schrieb am 13.03.2019 18:44

Noch eine Ergänzung dazu. Ich würde es ganz einfach machen (also nicht für die Entwickler, sondern für den Nutzer :D). Es gibt ein Input und ein Output Node. Diese können parametriert werden mit Quelle und Datenpunkt. Z.b. Softdesk_1→Button_1, könnte aber auch Tastatur→Taste Q sein.

Project Manager
Qasi schrieb am 13.03.2019 19:12

Bin ich dagegen!

Project Manager
Qasi schrieb am 13.03.2019 19:20

Also, Inputs bleiben Input und Outputs bleiben Outputs, die werden nicht in Nodes zusammengefast(Weil die zur laufzeit unendlich viele sein können, ein Node mit unendlich Ports macht null sin).
Einzig allein die möglichkeit über Propertys auf In oder Output ähnlich wie bei den Nodes würde ich aktzeptieren

Project Manager
Soon5 schrieb am 13.03.2019 20:49

Das meine Ich. Es wäre ein "Softdesk" Node, mit genau einem "Input" oder einem "Output", aber mit dem Unterschied, dass der Input / Output zur Laufzeit geändert werden kann.

Oder anderes Beispiel einen "DMX-IN" Node, wo über einen "Input" eingestellt werden kann auf welchen DMX-IN Kanal gelauscht werden kann.

Ein "Softdesk" Node, der auf ein "Softdesk" zeigt und dann dynamisch pro Slider / Button einen Port generiert ist nix.

Project Manager
Qasi schrieb am 13.03.2019 21:07

Ich meinte, das die Inputs und Outputs nur das Menü krigen, nicht noch einen weiteren Port

LightningBrothers schrieb am 13.03.2019 21:19

Richtig... Mehr wollte ich auch gar nicht. Das Node hat nur einen Anschluss und ich kann in den Properties festlegen, was ich damit verknüpfe. Hier wäre halt nur die Frage, wie weit man das treibt und verallgemeinert (am Beispiel des Softdesks):

  • Abgrenzung nach den Bedienelementen wie Slider, Button, Label etc.
  • Abgrenzung nach den unterschiedlichen Softdesks (also Softdesk A, Softdesk B)
  • Keine Abgrenzung (im Node sind alle Elemente aller Softdesks zu erreichen)
Project Manager
Qasi schrieb am 13.03.2019 21:25

Dieser Umbau wird dann alle bestehenden Graphen lahm legen

LightningBrothers schrieb am 13.03.2019 21:55

Hmm... Habe ich mir irgendwie schon fast gedacht. Gefühlt dürfte dies im Verhältnis nicht gar so schwer wiegen wie bei den Cuelist-Nodes (das ist aber mein subjektiver Eindruck).

Optimal wäre hier natürlich, wenn man dies noch im Laufe des Beta-Tests anpassen würde.

Project Manager
Soon5 schrieb am 14.03.2019 09:18

@Patrick
Wie meinst du das? Ich denke das kann man im Nachhinein einbauen ohne dass bestehende Graphen kaputt gehen. Man kennt ja den Input (die Source) und kann das dann als Einstellung vorbelegen. Da muss man etwas Konvertierungscode schreiben, ja, aber jetzt auch keine hunderten von Zeilen.

Für den Beta Test sehe ich das nicht mehr. Ist auf jedenfall frühestens was in 3.2.1.

nutzer99 schrieb am 14.03.2019 15:12

Was macht mehr arbeit? Jetzt umbauen und testen, oder später umbauen und nen Konverter basteln? Ist klar wenn das jetzt drei Wochen dauert, dann sollten wir das verschieben :). Aber bevor sich die Infrastruktur für die User wieder ändert und wieder Kompatiblitätsprobleme auftreten, sollten wir das ordentlich machen.

Mein Ansatz war eigentlich, wie Patrick schon meinte, dass es ein Input Node gibt mit einem Ausgang und 2 Parametern. z.b. Softdesk 1 - Button 1
Das Gleiche auch bei den Outputs.
Das hätte den riesigen Vorteil, dass man eine komplett fertig vorparametrierte Verbindung später mal kopieren kann und einfach mit anderen In/Outs versehen kann. Und das unabhängig der Hardware. So kann ich Cuelist A vom Softdesk und Cuelist B vom Midipult aus bedienen.

Project Manager
Qasi schrieb am 14.03.2019 15:20

Interessant, wie meine worte verdreht werden xD
Ich sags nochmal, ich möchte NICHT, das an Inputs uns Outputs weitere Ports kommen

nutzer99 schrieb am 14.03.2019 15:23

Hä?
Ich rede doch nicht von Ports, sondern von der Parametrierung der Nodes? Oder reden wir aneinander vorbei?

LightningBrothers schrieb am 14.03.2019 15:28

Ich glaube, Joseph meint hier nicht Ports. Ich habe es so verstanden, dass er einen allgemeingültigen Input- bzw. Output-Node schaffen möchte, der in seinen Properties zwei Parameter erhält:

  • Parameter 1: Auswahl zwischen Softdesk, Tastatur, MIDI etc.
  • Parameter 2: Konkretes Steuerelement wie Taste A wenn Tastatur gewählt, Button 2 oder Slider 5 wenn Softdesk gewählt

Damit kann man halt die gesamte Verbindung kopieren und ändert den Input von MIDI auf Softdesk, ohne auch nur irgendein Node löschen oder ersetzen zu müssen.

Project Manager
Soon5 schrieb am 15.03.2019 10:04

Mir ist eben noch eine alternative Idee gekommen, wie man das einbauen könnte, die ich hier einfach auch mal zur Diskussion werfen will. Anstelle über "Einstellungen" zu arbeiten würde ich ein "Input" bzw. "Output" Replace einbauen. Workflow könnte sein, ich ziehe per Drag & Drop einen "Input" auf einen bereits existierenden Input im Graphen. Dadurch würde der bestehende Input durch den neuen ersetzt werden (inkl. aller Verbindungen). Vorteil, der User würde ganz normal den "Neuen" Input im Baum suchen. Voraussetzung wäre natürlich dass das direkte Drag & Drop von Inputs / Outputs in den Graphen implementiert ist, aber das steht ja auf der ToDo Liste. Gefühlt wäre auch der Implementierungsaufwand geringer.

LightningBrothers schrieb am 15.03.2019 10:19

Wer hat dir denn diesen Floh ins Ohr gesetzt? :D Hust  FS#3415 , zweiter Kommentar Hust ;-)

Den Vorschlag finde ich aber für diesen Fall ebenfalls gut und er wäre durchaus nochmal komfortabler, weil ich die Änderung so deutlich einfacher und schneller schneller in den Graphen bekomme.

Project Manager
Soon5 schrieb am 15.03.2019 10:24

Lustig, den Kommentar hab ich ehrlich gar nicht gesehen :-D. Da sind wir unabhängig voneinander auf die gleiche Idee gekommen. Du aber Dokumentiert, 2 Tage früher :D

EDIT: Was man machen müsste allerdings wäre, anstelle von "Inputs" / "Outputs" aus Graphen zu löschen, wenn z.B. der entsprechende Softdesk Regler entfernt wird, müsste man diese in einen "Not Connected" Zustand versetzen, den man evtl. auch andersfarbig darstellt. Gleiches könnte man für Wrapper Knoten machen, wenn z.B. keine Cuelist zugewiesen ist. Diese "Not Connected" Inputs könnte man dann durch ersetzen / neu konfigurieren entsprechend wieder zum Leben erwecken.

Wichtig ist dabei, diesen "Not Connected" Zustand braucht man sowieso, egal ob man es per Drag & Drop oder über Einstellungen löst, macht also bezogen auf die beiden Lösungsvorschläge keinen wirklichen Unterschied.

LightningBrothers schrieb am 15.03.2019 10:31

Hehe... Ich merke gerade, dass dieses Ticket (sofern der Drag&Drop-Vorschlag allgemein zusagt) am Ende überflüssig ist weil doppelt und ich es eigentlich auch gar nicht hätte anlegen müssen, da ein Lösungsansatz quasi schon auf dem Tisch lag - außer der Wunsch soll / darf weiterhin bestehen bleiben, Inputs und Outputs langfristig auch in den Properties selbst ändern zu können.

LightningBrothers schrieb am 15.03.2019 10:48

Bezüglich dem Fall, ich habe einen Input oder Output gelöscht: zumindest im Falle des Softdesks arbeitet das Input Assignment bereits so, sodass ich den Input / Output durch das Ablegen eines anderen Buttons, Sliders etc. reparieren und die gesamte Verbindung wieder in den funktionsfähigen Zustand versetzen kann. Hier wäre nur die Frage, ob sich ein Input / Output mit dem Status "Empty" / "Not connected" optisch besser hervorheben lässt, sodass dies gerade in umfangreicheren Graphen schneller ins Auge fällt oder der User auf einem anderen Wege ein Feedback erhält, dass Inputs / Outputs oder auch Nodes leer sind.

Project Manager
Soon5 schrieb am 15.03.2019 10:48

Ich bin hier für eine Lösung. Zwei unterschiedliche macht meiner Ansicht nach keinen Sinn. Jetzt warten wir mal ab, was die anderen noch dazu für eine Meinung haben.

Project Manager
Qasi schrieb am 15.03.2019 13:52

Mit dem Drag and Drop hast du aber das Problem, das mann wissen muss, das das geht.
Mit den Propertys findet mann das schneller heraus, weil es sich gleich zu den Classen-Nodes verhält.

Mann müsste im optimalfall beides haben, Drag and Drop ersetzt einen Source/Sink
Propertys ändern die beziehungen im hintergrund

Project Manager
Soon5 schrieb am 15.03.2019 14:04

Also ein Property alleine bringt für mich keinen Mehrwert. Wenn wir das als Property einbauen wollen, dann würde ich aber auch vorschlagen, dass wir neben den "Fixed" Inputs / Outputs einen "Dynamic Input" haben, der ähnlich wie die Classen Nodes über einen Eingang verfügt, mit dem ich dynamisch den Eingang definieren kann.

Das "Property" bei den Classen Nodes kommt nämlich daher, dass die einen Eingang haben, und ich über das Property diesen Eingang setzen kann.

EDIT: Diesen "Dynamic Input" würde ich dann aber als "Node" definieren, und nicht als "Input" im Klassischen Sinne, also ähnlich wie die aktuellen Nodes.

Project Manager
Qasi schrieb am 15.03.2019 14:29

Für Drag and Drop, mus das Drag and Drop aber erstmal gehen

Project Manager
Soon5 schrieb am 17.03.2019 15:00

Touché

Project Manager
Soon5 schrieb am 20.03.2019 19:53

Also, Drag & Drop wie in  FS#3415  beschrieben geht jetzt. Ich finds eigentlich ne coole Lösung. Hab das Ticket auf "Testen" gesetzt. Wir können das dann in Beta 2 zumachen wenn das so für alle passt.

Lade...

verfügbare Tastenkürzel

Aufgabenliste

Aufgabendetails

Aufgabenbearbeitung