Probleme bei Umwandlung von mono zu poly

[PrinzThomas]

Hallo,

ich habe eigentlich Jahrelang immer nur monophone synthies erstellt - so direkt weiß ich es jetzt auch nicht warum. ^^
Nun dazu gehört auch ein Synthie an dem ich jetzt schon fast 2 Jahre rumbastle.
Er wird immer komplexer, sodass ich selbst Mühe habe durchzusehen - ich möchte ihn auch nicht unbedingt hier hochladen.

Nun habe ich mir einmal gedacht warum nicht mal mit mehreren Voices arbeiten.
Also fix 2 Voice-Combiner an das Ende der Kette und alle roten Kreuze mit einem davorgeschaltenen E } (Event VC all) ausgeknipst.
Dann die Voices vom Instrument hochgesetzt.
Dieses Vorhaben war wohl leider viel zu naiv zu glauben, dass ich dadurch meinem Synth auf die schnelle mehr Voices beibringe.^^
Folgende Problem sind mir leider sofort entgegen getreten:

1. Wenn ich mehr als 2 Voices einstelle spielt der Synthie seltsamerweise auch mehrere Noten wild gleichzeitig ab obwohl ich nur ein Taste drücke.

2. Mit jedem zusätzlichen Voice verdoppelt sich die Lautstärke am Ausgang.
Ich muss bei 6 Voices bereits den Output auf -40db regeln.

3. Meine Auslastung verdoppelt sich fast mit jeder zusätzlichen Voice.
Ist ein Sound mit einer Voice - also monophon - bei vielleicht 3% Auslastung und ich stelle 6 Voices habe ich dann fast 20% Auslastung.

Also was polyphonie im Reaktor angeht bin ich ein absoluter Noob und bräucht ein wenig eure Hilfe und Tipps, was man grundsätzlich beachten sollte.
Vielleicht muss ich ja bereits das Midi Gate verändern oder irgendwelche anderen Sachen - keine Ahnung.
Bitte um Hilfe.

Dank an alle Antworten.

[PrinzThomas]

Nachtrag:
Nach Stunden der Suche habe ich 2 der 3 Probleme gelöst.
1. Die Lautstärkeverdopplung hatte den Grund, dass ich bereits vorher schon mal 2 Voice Combiner eingesetzt hatte.

2. Das immer mehrere Töne bei einem Tastendruck gleichzeitig gespielt wurden hatte folgenden Grund:
Ich habe einen kleinen Sequencer, der die gesetzten Gate Signale an mein ADSR überträgt.
Die Übertragung hatte ich mittels Send und Receive Modul gelöst damit ich ein wenig Verdrahtung aus den verschachtelten Macros heraus spare.
Leider funktionieren bei mehr als 1 Voice sämtliche Sends nicht mehr, sodass ich als Lösung ein Event VC all davorgeschalten habe.
Das hat mir allerdings der ADSR übel genommen und immer mehrere Töne gleichzeitig angespielt.
Ich musste zwangsläufig nach außen verdrahten und jetzt funktioniert es soweit.
Gibt es eine Lösung wie man trotzdem Events via Send übertragen kann bei mehr als 1 Voice?
Ähnliches Problem ergibt sich mit Lampen oder Numeric Reads.
Wie schließt man diese denn bei polyphoner Schaltung an?
Ist da ein Event VC all davor korrekt?

Bleibt leider nur noch das Problem der Auslastung.
Ich habe bereits alle Effekte nach den Voice Combiner geschalten - so wie es sich ja auch gehört.
Leider ist das immer noch nicht akzeptabel.
Z.B habe ich mit einem einzelnen Sinustone ca 2% Auslastung bei einer Voice - das ist gemessen an dem Projekt ganz ok.
Wenn ich nun auf 6 Voices schalte rennt die Auslastung auf ca. 5% hoch.
Ein andere komplexer Sound hat z.B. bei mir 12% bei einer Voice und 20% bei 6 Voices.
Ich finde das zu viel - was könnte ich denn noch falsch haben?

[herw]

Nachtrag:
Nach Stunden der Suche habe ich 2 der 3 Probleme gelöst.
1. Die Lautstärkeverdopplung hatte den Grund, dass ich bereits vorher schon mal 2 Voice Combiner eingesetzt hatte.

2. Das immer mehrere Töne bei einem Tastendruck gleichzeitig gespielt wurden hatte folgenden Grund:
Ich habe einen kleinen Sequencer, der die gesetzten Gate Signale an mein ADSR überträgt.
Die Übertragung hatte ich mittels Send und Receive Modul gelöst damit ich ein wenig Verdrahtung aus den verschachtelten Macros heraus spare.
Leider funktionieren bei mehr als 1 Voice sämtliche Sends nicht mehr, sodass ich als Lösung ein Event VC all davorgeschalten habe.
Das hat mir allerdings der ADSR übel genommen und immer mehrere Töne gleichzeitig angespielt.
Ich musste zwangsläufig nach außen verdrahten und jetzt funktioniert es soweit.
Gibt es eine Lösung wie man trotzdem Events via Send übertragen kann bei mehr als 1 Voice?
Ähnliches Problem ergibt sich mit Lampen oder Numeric Reads.
Wie schließt man diese denn bei polyphoner Schaltung an?
Ist da ein Event VC all davor korrekt?

Bleibt leider nur noch das Problem der Auslastung.
Ich habe bereits alle Effekte nach den Voice Combiner geschalten - so wie es sich ja auch gehört.
Leider ist das immer noch nicht akzeptabel.
Z.B habe ich mit einem einzelnen Sinustone ca 2% Auslastung bei einer Voice - das ist gemessen an dem Projekt ganz ok.
Wenn ich nun auf 6 Voices schalte rennt die Auslastung auf ca. 5% hoch.
Ein andere komplexer Sound hat z.B. bei mir 12% bei einer Voice und 20% bei 6 Voices.
Ich finde das zu viel - was könnte ich denn noch falsch haben?

Das Problem, dass du nun mehrere Töne eventuell gleichzeitig hörst, die eigentlich getrennt auftreten sollten, könnte daran liegen, dass du vielleicht noch in irgendeinem Makro monophon das Voice- oder das Gatemodul einfädelst.
Send-Receive-Verbindungen können selbstverständlich polyphon sein. Da musst Du etwas falsch gemacht haben.
Also alles auf polyphon stellen und nur vor den Effekten den audio-voice-combiner einfügen und die Effekte alle auf monphon schalten, wenn du nicht unbedingt einen polyphonen Hall etc. benutzen möchtest.
Die Lautstärkeanpassung muss in der Tat an die jeweilige Zahl der Voices angepasst werden. Daher gibt es ja auch in der Regel den Master-Volumenregler.
Die Auslastung mit zwei Prozent ist nichts. Wenn ich ein leeres Ensemble benutze, liege ich natürlich schon bei 0,7%.
Eine Auslastung auf 12% ist wenig.
Da solltest Du Dir mal einige komplexe Ensembles anschauen. Dort kann man locker auf 30% und mehr kommen.
Anspruchsvolle Ensembles erfordern anspruchsvolle Rechenleistung.

ciao herw

[PrinzThomas]

Ich meinte natürlich das "IC Send".
Sobald ich mehr als eine Voice einstelle erscheint sofort ein rotes Kreuz.
Das bekomme ich nur mit einem davor geschaltenen "E }" wieder hin.
Ich nutze wirklich sehr viele dieser IC sends um mit einem Knopf ein Switch zu steuern.
Z.B. wenn der MIX Regler auf null steht schaltet automatisch das Switch auf off.
Das Problem ist auch bei allen Levels, Lampen und Numeric Reads.
Davon habe ich echt eine Menge und wenn ich bei jedem erst ein "E }" davorschalten muss bin ich Weihnachten vielleicht fertig damit. ^^
Außerdem weiß ich nicht, ob man das mit dem Event VC all überhaupt so löst.
Auf dem Screenshot habe ich mal schnell eine normale Schaltung zusammengebaut damit du siehst, was ich überhaupt meine.
Bei einem Numeric Readout oder einer Lamp reicht es bereits wenn ich eine Rechenoperation nach einem Knopf setze und es erscheint das rote Kreuz.
Wie bereits gesagt bekomme ich das mit dem "E }" weg, aber bin mir nicht sicher, ob man das überhaupt so macht.
Wenn ich das NOT Modul oder das Rechenmodul auf Mono schalte funktioniert es auch - ist das die bessere Lösung?

[herw]

Ich meinte natürlich das "IC Send".
Sobald ich mehr als eine Voice einstelle erscheint sofort ein rotes Kreuz.
Das bekomme ich nur mit einem davor geschaltenen "E }" wieder hin.
Ich nutze wirklich sehr viele dieser IC sends um mit einem Knopf ein Switch zu steuern.
Z.B. wenn der MIX Regler auf null steht schaltet automatisch das Switch auf off.
Das Problem ist auch bei allen Levels, Lampen und Numeric Reads.
Davon habe ich echt eine Menge und wenn ich bei jedem erst ein "E }" davorschalten muss bin ich Weihnachten vielleicht fertig damit. ^^
Außerdem weiß ich nicht, ob man das mit dem Event VC all überhaupt so löst.
Auf dem Screenshot habe ich mal schnell eine normale Schaltung zusammengebaut damit du siehst, was ich überhaupt meine.
Bei einem Numeric Readout oder einer Lamp reicht es bereits wenn ich eine Rechenoperation nach einem Knopf setze und es erscheint das rote Kreuz.
Wie bereits gesagt bekomme ich das mit dem "E }" weg, aber bin mir nicht sicher, ob man das überhaupt so macht.

Nein das macht man tatsächlich nicht so, da man den Knopf ohnehin über die properties direkt mit anderen Elementen verknüpfen kann.
Abgesehen davon kann man, da ja der Knopf in der Regel nur monophon angewendet wird (auf allen voices derselbe Wert), die anschließende Rechenoperation ebenfalls auf mono setzen und damit an das IC-send übergeben.
IC-send-receive-Verbindungen sind in der Tat immer monophon, da ihr einziger Zweck ist, Steuerdaten zu übergeben. Dafür kann man die Daten aber auch über verschiedene Instrumente schicken, was mit den normalen Send-Receive-Verbindungen nicht geht.

herw

[PrinzThomas]

Ich dachte es mir fast. ^^
Dennoch komme ich bei manchen Sachen nicht drum rum ein "E }" vor zu schalten, weil ich das vorhergehende Modul nicht auf mono stellen kann, da es polyphone signale verarbeiten muss.
Jetzt stellt sich aber die Frage, ob diese "E }" Module sehr an der Performance nagen.

Noch mal wegen der Auslastung.
Die meisten der polyphonen Reaktor Synthies andere Entwickler haben eine bedeutend geringere Auslastung, obwohl sie sehr komplexe Sounds erstellen.
Irgendwas ist bei mir nicht ganz korrekt.
Wahnsinn ist z.B. dass ein einzelner Filter bei 6 Voices bereits mind. 5% mehr auslastet.
Vielleicht muss ich das Gate Signal ja noch modifizieren.

Gibt es im Übrigen eine Möglichkeit die Anzahl der Voices über einen Knopf im Instrument selbst zu regeln?
Das wäre sehr praktisch, denn so könnte man Sound wie Bässe usw. monophon setzen und als Snapshot speichern.
Das spart bei einigen Sounds dann eine Menge unnütz verbratener Performance.

[herw]

Ich dachte es mir fast. ^^
Dennoch komme ich bei manchen Sachen nicht drum rum ein "E }" vor zu schalten, weil ich das vorhergehende Modul nicht auf mono stellen kann, da es polyphone signale verarbeiten muss.
Jetzt stellt sich aber die Frage, ob diese "E }" Module sehr an der Performance nagen.

Noch mal wegen der Auslastung.
Die meisten der polyphonen Reaktor Synthies andere Entwickler haben eine bedeutend geringere Auslastung, obwohl sie sehr komplexe Sounds erstellen.
Irgendwas ist bei mir nicht ganz korrekt.
Wahnsinn ist z.B. dass ein einzelner Filter bei 6 Voices bereits mind. 5% mehr auslastet.
Vielleicht muss ich das Gate Signal ja noch modifizieren.

Gibt es im Übrigen eine Möglichkeit die Anzahl der Voices über einen Knopf im Instrument selbst zu regeln?
Das wäre sehr praktisch, denn so könnte man Sound wie Bässe usw. monophon setzen und als Snapshot speichern.
Das spart bei einigen Sounds dann eine Menge unnütz verbratener Performance.

Zur letzten Frage antworte ich mal zuerst: klar kann man das machen; es gibt mehrere Ensembles, die sich von polyphon auf monophon umschalten lassen (Razor zum Beispiel). Schau dir das absolute Spitzenensemble 3X.ens von James Walker Hall aus der user library an; dort findest Du alle Hinweise.

Du musst unterscheiden zwischen dem Audio-Voice-Combiner } und dem Event-Voice-Combiner E} .
Der Audio-Voice-Combiner addiert alle Audio-voices zu einer Audiosumme und man erhält ein monophones Audiosignal; der Event-Voice-Combiner wandelt polyphone Eventsignale in sequentielle Eventsignale um, d.h. er greift auf den polyphonen Eventdatenfluss zu und gibt ohne Berücksichtigung, von welcher voice der Event kommt, den jeweiligen Wert monphon weiter.
Über die jeweiligen Auslastungen kann man pauschal nichts sagen, wenn man die Struktur nicht kennt, abgesehen davon, dass mancher CPU-Verbrauch schon aus prinzipiellen Gründen nicht angezeigt wird.
Vermengt man Event und Audiosignale, kann man böse Überraschungen erleben. Das kann ich aber hier nicht im Einzelnen ausführen, da das nicht trivial zu begründen ist.
Zur absoluten Belastung von 5% durch ein Filter kann ich nicht viel sagen, zum Vergleich: auf meinem MacBookPro 2,8GHz Intel Core 2 Duo komme ich bei einem Core-D/T Ladderfilter auf knapp 3,1% mit 6 Voices; diese Werte kann man aber nicht wirklich ernst nehmen.
REAKTOR leistet viel, aber verbraucht auch viel. Trotzdem kann man durch geschickte Programmierung der Struktur durchaus den Gesamtverbrauch eines sehr anspruchsvollen Ensembles etwa zwischen 20% und 30% halten. Manche Ensembles haben aber auch einen „bombastischen” Sound und verbrauchen trotzdem wenig. Es gibt hier keine allgemeine Regel.
In Cubase laufen sogar mehrere Instanzen von REAKTOR klaglos. Man kann also nicht einfach Prozentzahlen addieren.
Es gibt einige Tricks, wie man CPU-Verbrauch stark reduzieren kann. Dazu muss man sich aber in die typischen „großen” Ensembles hineindenken.
Beispiele sind die Ausnutzung, dass man polyphone Audiostränge auch als mehrfachen monophonen Strang nutzen kann (zum Beispiel beim Hall), oder Abschaltung der SampleRateClock in AudioCoreCells bei zeitweisem Nichtbenutzen einer Voice.
Das ist nicht einfach.

ciao herw

[PrinzThomas]

Ein simpler Umschalter zwischen mono und poly mittels einem switch oder Relay und 2 Gates (eines auf mono gestellt) löst doch mein Problem nicht.^^
So einen Umschalter hatte ich bereits in den ersten Reaktor Tagen gebaut.
Ich dachte eher an einen Umschalter, der auch Sinn macht - indem er dadurch die CPU-Auslastung herunterdrückt.
Oder besser einen Regler mit denen man die Voiceanzahl einstellen kann, aber ich vermute stark, dass dies leider unmöglich ist.
Eigentlich ein massiver Fehler seitens NI so etwas nicht mit anzubieten - falls meine Vermutung richtig ist.

Die Wirkungsweise der Combiner sind mir schon bekannt sonst hätte ich es ja erst gar nicht zur Polyphony geschafft.
Es geht eigentlich vielmehr darum, ob ein Event VC in größerer Zahl vielleicht zu viel Auslastung verursacht und man deshalb nach anderen Lösungen suchen sollte.

Nur ein Beispiel, was den Nutzen von Event VC angeht:
Der Ausgang des LFOs wird optisch mit einer LevelLamp dargestellt.
Wenn ich den LFO aber polyphon betreiben möchte kann ich das Modul wohl kaum einfach auf mono stellen damit die Lamp funktioniert.
Hier setze ich dann eben ein Event VC vor die Lamp.
Oder wie würdest du das dann lösen?
Und genau solche Sachen sind eine Menge im Synthie.

Noch eine andere Sache:
Es ist wirklich nervig, dass Dinge, die man in einer Table - z.B. als Arpeggiator - einträgt einfach nicht mit als Snapshot gespeichert werden - bzw. dieses nur global für das gesamte Ensemble.
Ich nutze natürlich die Möglichkeit mehrerer Presets, um verschiedene Inhalte für verschiedene Sounds zu speichern, aber leider werden eben mit dem Speichern des Sounds als Snapeshot nur die Presetnummer gespeichert und nicht der Inhalt der Tabelle.
Der Inhalt wird dummerweise nur global als Ganzes und nur einmal im Instrument gespeichert.
Das ist - wenn man es mal genau betrachtet - unglaublich unprofessionell und nervig.
Warum speichert Reaktor nicht immer den kompletten Tabelleninhalt in ein Snapshot?
Das würde alle Probleme sofort lösen.
Oder gibt es dafür einen Lösungsweg?

[herw]

Ein simpler Umschalter zwischen mono und poly mittels einem switch oder Relay und 2 Gates (eines auf mono gestellt) löst doch mein Problem nicht.^^
So einen Umschalter hatte ich bereits in den ersten Reaktor Tagen gebaut.
Ich dachte eher an einen Umschalter, der auch Sinn macht - indem er dadurch die CPU-Auslastung herunterdrückt.

NI kann nicht jede Voice-Anwendung vorhersehen. Was für dich wichtig erscheint, ist für andere unwichtig. Hier ist wirkliche (eigene) Programmierphantasie angesagt. Eine eigene Voice-Verwaltung ist schwierig, da man auf primary-Ebene zwischen polyphonen (ControlRate-) Events und Audio-Events unterscheiden muss. Da muss man mit den ToVoice, den FromVoice- und den VoiceShift-Modulen arbeiten. Dies in die Core-Ebene hinüberzutragen ist extrem aufwändig.
Man könnte auch vermuten, hier mit Instrumenten unterschiedlicher Voice-Zahl zu arbeiten. Das führt häufig zu Abstürzen.

Oder besser einen Regler mit denen man die Voiceanzahl einstellen kann, aber ich vermute stark, dass dies leider unmöglich ist.
Eigentlich ein massiver Fehler seitens NI so etwas nicht mit anzubieten - falls meine Vermutung richtig ist.
[...] Nur ein Beispiel, was den Nutzen von Event VC angeht:
Der Ausgang des LFOs wird optisch mit einer LevelLamp dargestellt.
Wenn ich den LFO aber polyphon betreiben möchte kann ich das Modul wohl kaum einfach auf mono stellen damit die Lamp funktioniert.
Hier setze ich dann eben ein Event VC vor die Lamp.
Oder wie würdest du das dann lösen?
Und genau solche Sachen sind eine Menge im Synthie.

Das habe ich gelöst, indem ich parallel zum eigentlichen (polyphonen) LFO mit derselben Frequenz einen monophonen LFO mit einer Lamp laufen lasse (siehe Modular M1). Das verbraucht wenig CPU.
Wie schon in der letzten Post erwähnt, kann ich hier wieder nur pauschale Antwort liefern. Wenn Du ein großes komplexes Ensemble planst, musst Du selbst untersuchen, wo die CPU-Fresser sind, dies abändern oder eben Kompromisse suchen.

Noch eine andere Sache:
Es ist wirklich nervig, dass Dinge, die man in einer Table - z.B. als Arpeggiator - einträgt einfach nicht mit als Snapshot gespeichert werden - bzw. dieses nur global für das gesamte Ensemble.
Ich nutze natürlich die Möglichkeit mehrerer Presets, um verschiedene Inhalte für verschiedene Sounds zu speichern, aber leider werden eben mit dem Speichern des Sounds als Snapeshot nur die Presetnummer gespeichert und nicht der Inhalt der Tabelle.
Der Inhalt wird dummerweise nur global als Ganzes und nur einmal im Instrument gespeichert.
Das ist - wenn man es mal genau betrachtet - unglaublich unprofessionell und nervig.
Warum speichert Reaktor nicht immer den kompletten Tabelleninhalt in ein Snapshot?
Das würde alle Probleme sofort lösen.
Oder gibt es dafür einen Lösungsweg?

Natürlich gibt es dafür einen Lösungsweg; aber wie schon oben erwähnt, REAKTOR ist eine Entwicklerumgebung. Jede Anwendung muss man selbst erstellen, sonst geht REAKTOR über in einen Spezialanwendungsbaukasten. Ich vergleiche mal mit LEGO: wieviel konnte man mit den Standardklötzchen erreichen und welche Abhängigkeit hat man sich durch Spezialbausteine geschaffen?
Das Abspeichern von Eventtabledaten musst Du selbst in die Hand nehmen. Dies geschieht über SnapshotArrays. Das Speichern und Abrufen über eine allgemeine Lösung ist eine wirklich anspruchsvolle Tätigkeit und man muss sich jede Menge eigener Algorithmen überlegen, damit es zum eigenen Ensemble passt.
Hier ist viel Grundlagenarbeit nötig. Auch hier ist eine generelle Lösung mit viel Aufwand nötig. Iterationen und Eventbusse spielen hier eine wesentliche Rolle.
Einen kleinen Einblick kannst Du im Modular M1 erahnen.
Der (noch) nicht veröffentlichte Modular X benutzt diese Technik beim Abspeichern der Bildschirmkabel.

ciao herw

[PrinzThomas]

NI kann natürlich nicht jede Anwendung vorhersehen - das ist ja klar, aber hat doch nichts mit dem geschilderten Problem zutun.
Was spräche dagegen ein Modul anzubieten bei denen man aus dem Instruement heraus die Voices für das Instrument setzen kann.
Anstatt im Reaktor in den Instrumenten Proberties zu schrauben kontrolliert man dies eben im Instrument.
Dann hätte man auch die Möglichkeit die Voiceanzahl mit Snapshots zu speichern.
Snapshots kann ich ja auch aus dem Instrument heraus kontrollieren (umschalten, speichern usw.) obwohl dies eigentlich nur eine Proberties Funktion des Instrumentes ist - wie eben auch die Anzahl der Voices.

Ja und natürlich ist Reaktor eine Entwicklungerumgebung, aber das ist doch kein Argument, denn - warum muss ich für ein Tabelle extra umständlich Dinge entwicklen, um diese mit einem Snapshot mitzusichern und bei allen anderen Werten wie Knöpfe, Switches usw. brauche ich es nicht.
Das ist nicht logisch.
Dann hätte NI so konsequent sein müssen und auch das Speichern von Reglerwerten auf Entwicklung setzen müssen.

Du würdest eher ein zweiten LFO extra für die Lamp aufbauen als anstatt nur ein event Combiner davor zu schalten?
Das hieße ja, dass du entweder weißt, dass der EventCombiner mehr CPU verbraucht oder die Möglichkeit es so zu lösen bisher gar nicht in Betracht gezogen hast.

[herw]

[...]
Du würdest eher ein zweiten LFO extra für die Lamp aufbauen als anstatt nur ein event Combiner davor zu schalten?
Das hieße ja, dass du entweder weißt, dass der EventCombiner mehr CPU verbraucht oder die Möglichkeit es so zu lösen bisher gar nicht in Betracht gezogen hast.

Um eine Lampe anzusteuern, muss man ein monophones Signal erzeugen. Wenn der LFO polyphon sein soll, heißt das ja, dass du ihn in Abhängigkeit der Voices mit unterschiedlichen Frequenzen oder mit unterschiedlichen Phasen laufen lassen möchtest (ansonsten brauchst du keinen polyphonen LFO). Da macht eine monophone Lampe als Anzeigenelement ja überhaupt keinen Sinn, wenn du sie über einen EventCombiner steuerst.
Ich habe die Möglichkeit eines parallel dazu laufenden LFOs deshalb genutzt, da mein LFO auf der Basis einer AudioCoreCell einen Audioausgang besitzt. Die Lampe wird durch einen normalen primary LFO gesteuert.
Wenn du CPU sparen möchtest bleiben nur eigene Tests übrig; ich habe so für diesen Fall CPU einsparen können.
Aber wie schon oben erwähnt, schau es dir in Ensembles an, wie und warum bestimmte Lösungen genau so realisiert sind. Es gibt keine generelle Regel, um CPU einzusparen.

caio herw

[PrinzThomas]

Wenn der LFO polyphon sein soll, heißt das ja, dass du ihn in Abhängigkeit der Voices mit unterschiedlichen Frequenzen oder mit unterschiedlichen Phasen laufen lassen möchtest (ansonsten brauchst du keinen polyphonen LFO). Da macht eine monophone Lampe als Anzeigenelement ja überhaupt keinen Sinn, wenn du sie über einen EventCombiner steuerst.

Es geht nur darum, dass der LFO nicht mit jedem zusätzlichen Tastendruck neu für alle Töne gleichzeitig anfängt zu schwingen - sondern für jeden Tastendruck separat.
Dafür benötige ich einen polyphonen LFO.
Es geht also weniger um unterschiedliche Frequenzen sondern vielmehr um unterschiedliche Triggerzeitpunkte.
Das ist übrigens ein Standard in fast jedem polyphonen Synthesizer.
Mit einem vorgeschalteten EventCombiner erhalte ich zwar dadurch keine Triggergenaue Anzeige - es sei denn ich drücke nur eine Taste oder mehrere gleichzeitig, aber die hätte ich in diesem Fall mit einem extra dafür angelegten monofonen LFO nur für die Lamp natürlich auch nicht.
Es bleibt also nur die Frage, ob ein LFO Modul weniger an CPU benötigt als ein EventCombiner, obwohl ich da aus Logikgründen schon fast ungesehen darauf tippen würde, dass ein LFO natürlich merh verbraucht.
Aber ich werde das mal austesten.

[herw]

Wenn der LFO polyphon sein soll, heißt das ja, dass du ihn in Abhängigkeit der Voices mit unterschiedlichen Frequenzen oder mit unterschiedlichen Phasen laufen lassen möchtest (ansonsten brauchst du keinen polyphonen LFO). Da macht eine monophone Lampe als Anzeigenelement ja überhaupt keinen Sinn, wenn du sie über einen EventCombiner steuerst.

Es geht nur darum, dass der LFO nicht mit jedem zusätzlichen Tastendruck neu für alle Töne gleichzeitig anfängt zu schwingen - sondern für jeden Tastendruck separat.
Dafür benötige ich einen polyphonen LFO.
Es geht also weniger um unterschiedliche Frequenzen sondern vielmehr um unterschiedliche Triggerzeitpunkte.
Das ist übrigens ein Standard in fast jedem polyphonen Synthesizer.
Mit einem vorgeschalteten EventCombiner erhalte ich zwar dadurch keine Triggergenaue Anzeige - es sei denn ich drücke nur eine Taste oder mehrere gleichzeitig, aber die hätte ich in diesem Fall mit einem extra dafür angelegten monofonen LFO nur für die Lamp natürlich auch nicht.
Es bleibt also nur die Frage, ob ein LFO Modul weniger an CPU benötigt als ein EventCombiner, obwohl ich da aus Logikgründen schon fast ungesehen darauf tippen würde, dass ein LFO natürlich merh verbraucht.
Aber ich werde das mal austesten.

ja teste - ohne ein Beispiel können wir hier noch stundenlang erfolglos diskutieren. Was du mit dem eventcombiner als Hilfsmittel zur Anzeige machen möchtest, ist mir leider nicht klar geworden, insbesondere verstehe ich deine letzte Aussage nicht, wie und wozu du den CPU-Vergleich zwischen einem EventCombiner und einem LFO, also zwei völlig verschiedenen Modulen, machen möchtest.

Ein vergleichendes und klärendes Beispiel ist gut.

ciao herw

[PrinzThomas]

... insbesondere verstehe ich deine letzte Aussage nicht, wie und wozu du den CPU-Vergleich zwischen einem EventCombiner und einem LFO, also zwei völlig verschiedenen Modulen, machen möchtest.

Ehm... habe ich was verpasst?
Wir hatten doch kurz vorher diskutiert, ob die Lösung mit einem extra LFO für eine optische Anzeige evtl. CPU-sparender ist als die Variante mit dem EventCombiner.
Um das raus zu bekommen muss ich beide eben mit einander vergleichen.
Warum du das jetzt nicht verstehst ist mir ehrlich gesagt ein kleines Rätsel.

Aber mal eine andere Sache, die ich mir überlegte und auch noch soweit in meinen ersten Test funktioniert.
Da ich wie gesagt erst relativ neu in die polyphone Arbeitsweiße eintauche weiß ich allerdings nicht, ob diese "Idee" nicht sogar ein weitverbreiteter alter Hut ist.
Um massige Verdrahtung zu verhindern kann man einfach mehrere Signale zu einem poly-Signal mithilfe von To-V Module an der Quelle zusammenfassen und am Ziel dann mit From-V Modulen wieder splitten.
Ich habe das probiert und tatsächlich funktioniert das auch.
Nun stellt sich mir dir Frage, ob es nicht doch ein paar Nachteile geben könnte.
Mir fallen 2 auf Anhieb ein: 1. man darf natürlich nicht die Voices des Instrumentes heruntersetzen und 2. Wenn das "komprimierte" PolySignal ein auf monophon gestelltes Macro durchläuft sind vermutlich die Daten futsch.
Was meinst du dazu?

[herw]

... insbesondere verstehe ich deine letzte Aussage nicht, wie und wozu du den CPU-Vergleich zwischen einem EventCombiner und einem LFO, also zwei völlig verschiedenen Modulen, machen möchtest.

Ehm... habe ich was verpasst?
Wir hatten doch kurz vorher diskutiert, ob die Lösung mit einem extra LFO für eine optische Anzeige evtl. CPU-sparender ist als die Variante mit dem EventCombiner.
Um das raus zu bekommen muss ich beide eben mit einander vergleichen.
Warum du das jetzt nicht verstehst ist mir ehrlich gesagt ein kleines Rätsel.

Bitte lade die Struktur hoch, sonst missverstehen wir uns unaufhörlich

Aber mal eine andere Sache, die ich mir überlegte und auch noch soweit in meinen ersten Test funktioniert.
Da ich wie gesagt erst relativ neu in die polyphone Arbeitsweiße eintauche weiß ich allerdings nicht, ob diese "Idee" nicht sogar ein weitverbreiteter alter Hut ist.
Um massige Verdrahtung zu verhindern kann man einfach mehrere Signale zu einem poly-Signal mithilfe von To-V Module an der Quelle zusammenfassen und am Ziel dann mit From-V Modulen wieder splitten.
Ich habe das probiert und tatsächlich funktioniert das auch.
Nun stellt sich mir dir Frage, ob es nicht doch ein paar Nachteile geben könnte.
Mir fallen 2 auf Anhieb ein: 1. man darf natürlich nicht die Voices des Instrumentes heruntersetzen und 2. Wenn das "komprimierte" PolySignal ein auf monophon gestelltes Macro durchläuft sind vermutlich die Daten futsch.
Was meinst du dazu?

Das Prinzip von REAKTOR ist, dass es eigenständig polyphone Datensignale verwaltet. Warum du nun plötzlich die Verwaltung selbst übernehmen möchtest ist mir nicht klar. Die Monophonie ist ein Spezialfall der polyphonen Stimmenverwaltung von REAKTOR.
Vielleicht denkst Du, man müsste zunächst alles monophon erzeugen und dann polyphon zusammenfassen?
Wie schon oben erwähnt, ohne ein konkretes Ensemble kann ich dazu nicht Stellung nehmen.

ciao herw