- Status geschlossen
- Prozent erledigt
- 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
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.
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.
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.
Bin ich dagegen!
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
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.
Ich meinte, das die Inputs und Outputs nur das Menü krigen, nicht noch einen weiteren Port
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):
Dieser Umbau wird dann alle bestehenden Graphen lahm legen
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.
@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.
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.
Interessant, wie meine worte verdreht werden xD
Ich sags nochmal, ich möchte NICHT, das an Inputs uns Outputs weitere Ports kommen
Hä?
Ich rede doch nicht von Ports, sondern von der Parametrierung der Nodes? Oder reden wir aneinander vorbei?
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:
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.
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.
Wer hat dir denn diesen Floh ins Ohr gesetzt? :D Hust
FS#3415, zweiter Kommentar HustDen 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.
Lustig, den Kommentar hab ich ehrlich gar nicht gesehen . 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.
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.
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.
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.
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
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.
Für Drag and Drop, mus das Drag and Drop aber erstmal gehen
Touché
Also, Drag & Drop wie in
FS#3415beschrieben 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.