Ja, Scene Controller kann man gar nicht genug haben. Zumal sie selbst ja einen Workaround für ein anderes Problem, nämlich das der Gaps und Lags sind.
Es gibt durchaus Anwendungen für die Mehrfachbelegung eines Scene Controllers, das leuchtet mir ein. Jedenfalls ist es so natürlich ultraflexibel, partiell zwar nur, weil ja nun doch nicht alles gesteuert werden kann, aber man kann damit Dinge lösen, die ansonsten nicht lösbar wären. Und die Anwendung ist ja nicht auf kontinuierliche Parameter wie Volume, Drive usw. beschränkt, sondern es können auch Schaltfunktionen realisiert werden.
Für mich ist es dann aber erst recht klar, dass dann für die Selbstdokumentation mindestens ein sprechender Name weit sinnvoller ist als ein generischer.
Im FAS Forum wird diese Diskussion auch gerade geführt mit sehr ähnlichen Argumenten.
Wie ich schon schrieb, geht es mir dabei um die Bedienung auf dem Gerät selbst, für Proben, Gigs u.ä., wo ich wie viele andere auch prinzipiell kein FM3-Edit zur Hand haben und trotzdem unter Stress doch schnell mal etwas ändern muss, ohne sich im komplexen/komplizierten Bedienungsdschungel zu verlaufen. In FM3-Edit kann man sich die Parameter mit der Maus anzeigen lassen, auf dem Gerät selbst muss man sich entweder erinnern oder sich durch mehrere Sreens hangeln.
Es kostet einfach unnötig Zeit und Energie, wenn man es nicht direkt sehen kann, sondern sich durch das Preset hangeln muss.
Nicht, dass es etwas zur Sache tut:
Aber ich kenne diese Probleme durch ungeschickt programmierte UI und den Schaden, den es anrichten kann, wenn User sich auf teilweise sehr seltsame Bypass-Pfade begeben, selbst zur Genüge, da ich seit 30 Jahren Softwareprogrammierer bin. Meistens zwar im Daten-Backend, aber oft auch im Frontend, wo die Frage, wie man viele Megabytes Informationen möglichst knackig und übersichtlich auf einen leider nur zweidimensionalen Bildschirm mit einer dann doch recht begrenzten Anzahl von Bildpunkten so darstellt, dass ein User eben die größte Übersicht behält, um sich seinem eigentlichen Anliegen widmen zu können. Das hat nichts mit Faulheit oder Dummheit zu tun, sondern damit, sich als Programmierer der Userperspektive anzunehmen. Schwer umzusetzen, und immer kompromissbehaftet, oftmal nur in iterativen Entwicklungsschritten zu realisieren und nicht von vornherein planbar, weil sich auch die Anforderungen ändern werden.