Der Oszillator wurde heute gründlich untersucht.
Bisher habe ich quasi mit einer Kopie aus dem modular 1 gearbeitet.
alter Oszillator.jpg
Die Struktur ist eine Kombination aus primary- und core-level. Das war (bisher) nötig, um durch einen Schalter entsprechende Schwingungszweige CPU-mäßig abzukoppeln.
Nun habe ich die gesamte Struktur wieder in eine einzige Corecell gepackt und schalte nun im Innern. Dies hat auch noch zusätzlich den Vorteil, dass es keinen Globalen Reset gibt. Denkbar wären also später so kleine Kabinettstückchen, dass man über den Soft-Switch die Wellenform mit einem Audiosignal umschaltet, also zum Beispiel eine halbe Sinuswelle mit einem halben Sägezahn kombiniert; nur so eine Idee. Mit einem primary switch geht das wohl nicht.
neuer Oszillator.jpg
Ich habe auch mein Ziel erreicht, alle Panel-Daten über einen Eventbus {pn} einzuschleusen. Links oben werden die Daten durch den Mehrfach-Receiver aufgedröselt. D.h. ich bauche trotz vieler Bedienelemente nur
einen Eingang für die Corecell.
Die unteren vier Eingänge sind Audioeingänge, die von den Bildschirmbuchen kommen.
Natürlich war mein Ziel, wenigstens dieselbe Performance der alten Lösung zu erreichen.
Das konnte ich sogar noch unterbieten.
Ein etwas komplexer Patch mit vier Sinusschwingungen, wobei zwei der Oszillatoren zusätzlich noch die anderen beiden Oszillatoren frequenzmodulieren, verbrauchte mit dem alten Oszillator bei acht Stimmen ca. 24%. Mit dem neuen Oszillator nur noch knapp 18%.
Ich bin sehr zufrieden.
Trotzdem war das ganze nicht leicht. Das Umschalten der Schwingungsformen hat so seine Tücken.
Normalerweise würde man hier einfach durch eine Kontrollgröße einen Vergleich durchführen, hiermit einen Router schalten und die Schwingung durchlassen.
Das klappte auch teilweise, doch gab es aus unerfindlichen Gründen beim Sägezahn einen akustischen Crash und Prozessor-Overload.
Fragt mich jetzt nicht warum.
Jedenfalls habe ich dann mal ein Relay-Modul statt des Routers genommen und siehe da: es funktionierte.
Das ist natürlich mal verwunderlich, da das Relay-Modul ja ebenfalls einen Router enthält.
Allerdings gibt es dort einen feinen Unterschied, der mir schon oft in anderen REAKTOR-Modulen aufgefallen ist, ich aber noch nie verstanden habe; ich habe daraufhin eine reduzierte Struktur genommen, die denselben Zweck erfüllt:
soft switch.jpg
Beachtenswert ist zunächst, dass das Kontrollersignal und das Audiosignal (es handelt sich hier um die Phase des Ramp-Oszillators, den man in jedem Oszillator findet) durch einen Eventmerger verbunden sind und über den Router weitergeleitet werden. Dies erscheint mir im Nachhinein logisch, da ja das Kontroller-Event von einem Regler kommt und somit nicht mit dem Audiosignal synchron erscheint. Das Kontroller-Event ist nur ein einzelnes Event, während die Phase ph ja fortlaufend mit AudioRate erscheint.
Beim Umschalten erfolgt also quasi zwischen den Audioevents das Einschalten des Signalwegs. Hinter dem Router forciert dieses Signal die Phase durch ein Latchmodul.
Die Kombination mit dem Event-Merger brachte schließlich die Funktionssicherheit.
Den Soft-Switch kann ich nun auch in anderen Multi-Containern wie zum Beispiel dem Multifilter benutzen; es hat sich also gelohnt.
Damit nicht alles so trocken ist, habe ich mal von dem Patch ein kleines MP3-file erstellt: zwei Varianten desselben Patches (schön weihnachtlich).
Glöckchen.mp3.zip
ciao herw
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
.
nichts lief mehr; letztes Backup vom 3. November, d.h. 14 Tage Arbeit und 14 Tage Projektarbeit futsch 
. Mit einem kleinen Euro-Aufschlag hat Gravis mir in 2 Stunden eine neue Festplatte eingebaut. Die Daten waren nicht mehr erreichbar. Habe dann sofort eine größere Festplatte gewählt (500GB).