Routing Matrix in Core

[Thala]

Hallo,
ich würde gern eine effekt routing matrix bauen (mal gucken was da aus sicht der performance möglich ist).
ich hab hin und her überlegt, ob man dies mit switches in primary lösen sollte.
da ich die matrix wild modulieren wollte und deshalb wohl CPU sparen durch switches quasi passé ist, und ausserdem audioknackser vermeiden wollte, bleibt wohl nur eine wahl: core.
könnt ihr da bitte mal reinschauen? meine variante fühlt sich irgendwie nach "in primary denken" an, obwohl es core ist...
geht es eleganter?
mit besserer performance?
und mit crossfades anstatt switches?
gibt es evtl logische vereinfachungen, die massiv bauteile/performance ersparen würden und gleichzeitig crossfades ermöglichen?

im moment hat der core 9 stereo ein- und ausgänge.
jeder eingang lässt sich per fernbedienung auf jeden ausgang routen.
die ausgänge werden als effekt sends benutzt. diese speisen in macros gedockte instrumente, welche die effekte beinhalten (wegen separaten snapshots pro effekt und schneller austauchbarkeit). diese funktionalität sollte auch erhalten bleiben.
ich bin für jeden ratschlag dankbar.

[Quietschboy]

Soll dies eine Matrix für eine Effektkette darstellen? Also, daß die Ausgänge der Effekte wieder zurück an die Eingänge der Matrix geführt werden?

[Thala]

ja genau!

[Quietschboy]

OK.

Sind wir uns einig, dass es schon rein vom audiophilen Erlebnis her wenig Sinn macht, einen Effektausgang über die Routing-Matrix wieder in sich selbst zu führen? Auch wenn noch ein oder mehrere andere Effekte dazwischengeschaltet sind?
Entsprechend sollte die Logik des Routings ausgeführt sein. Es sollte also eine reine serielle Kette sein. Parallele Verschaltung darf auch gerne erlaubt sein. Nur keine Rückführung!

Die Routing-Matrix in Core auszuführen vereinfacht einiges. Dein Versuch mit den Routern ist durchaus schonmal OK, bis auf, dass eben die Rückverschaltung möglich und die Bedienung per acht Regler? äusserst umständlich ist.
Die Effekte in Primary oder in einer anderen Core Cell ("in Primary") anzuknüpfen ist die beste Wahl. Da hast du, wie du schon selbst sagst, die einfachste Möglichkeit Effekte auszutauschen. Das kann auch mittels Switches geschehen! Dafür, dass eine Umschaltung mittels Switch nicht unbedingt auch zu Knacksern führen muss, werde ich dir gleich noch ein Beispiel nennen. Man muss einfach nur aufpassen, an welcher Stelle man Re-Init Events erlaubt und evtl. dass der Re-Initialisierugsvorgang nicht "zu lange dauert" - im Sinne eines Audio-Buffer Underruns. Um einfach nur Sprünge im Audiosignal während des Re-Init zu unterbinden sind möglicherweise Crossfades hilfreich, welche aber womöglich einen Puffer, sprich eine Latenz, vorraussetzen. Aber das sind alles nur Details um dich bestmöglich aus der Spur zu bringen
Mit Switches lassen sich ungenutzte Effekt super einfach ausschalten und fallen der CPU somit nicht zur Last! 100 Punkte für Primary!

Würdest du alle deine Effekte, meinetwegen mitsamt der Routingmatrix, in eine Core Cell packen, würde sich für den grundsätzlichen Aufbau der Routingmatrix im Prinzip nichts ändern, bzw vereinfachen. Allerdings ist dann die Routingvariante über ein Array deutlich deiner Variante mit den Routern vorzuziehen.
Für die Core Cell selbst sparst du einen ganzen Haufen Ein- und Ausgänge. Das spart auch ganz real CPU. Allerdings ist es wesentlich mühsamer ungenutzte Effekte in Core komplett abzuschalten als in Primary. Also an dieser Stelle m. E. eher ein Minus für die Effekte in einer Core Cell. Außerdem sollte man auch abwägen, ob ganze 8 verkettete Effekte generell und somit eben auch 18 Audioein- und ausgänge (incl. In/Out) in der Routing Core Cell denn nicht ein wenig zu viel des Guten sind.
[edit:] Die Effekte in Core benötigen natürlich auch hier jeweils einige Event In- und Outports zu Primary für Panel Elements und Snapshots, etc.!

Die Routing Variante über ein ARRAY:
Der elegantere Weg, allein schon von der Übersicht her, ist es ein Core Array als Zwischenspeicher für die Audiosignale zu verwenden. Oder eben halt zwei Arrays für stereo.
Ich möchte das hier jetzt nicht ausarbeiten, sondern nur kurz andeuten:
Das Array selbst müsste gar nicht groß sein. Für neun Eingänge eben nur neun Felder/Indices/Indexe.
Jeder Eingang schreibt sein Audioevent in sein fest zugewiesenes Arrayfeld. Die Routinglogik bestimmt nun, für welchen Ausgang welches Feld per SR.C ausgelesen werden soll.
Das war´s im Prinzip schon.
Und das mit der Routinglogik ist jetzt nicht mein Problem

Und wenn du den kurzen Dienstweg nehmen willst, besorge dir MOLEKULAR. Dort ist genau DAS zur Perfektion gebracht worden und sofort spielbereit.

LG Mark

[Thala]

danke schonmal,
aber du hast mich garnicht so dolle aus dem tritt gebracht...
ich hab schon mal den ersten effekt gemacht, um den kopf zwischendurch frei zu bekommen. und bin dabei noch auf ein paar andere ideen gekommen.
eine davon ist nicht mehr mit routern zu arbeiten, sondern mit gates auf XR freezes, welche einfach den flow stoppen.
die logik ist nicht so das problem:
fx-routing-wert +0 = insert
fx-routing-wert+1 = send
und natürlich sollen rückführungen möglich sein (zuschaltbarer unlogischer modus...). kreischen muss das biest. wozu gibts denn sonst den "clip minmax" *gg*

und die sache mit molekular wollte ich eigentlich umgehen und gucken, ob das nicht auch besser/flexibler und mit random taste geht
das geld würde ich eher in polyplex investieren.
aber nach dem letzten telefonat mit dem NI-support werde ich mir genau überlegen, ob die überhaupt noch einen cent von mir bekommen...