MvK Monokl

Hier soll es ausschließlich um Arbeiten zu neuen und alten Ensembles gehen.

Moderator: herw

Benutzeravatar
wehkah
synthesist
Beiträge: 77
Registriert: 26. Januar 2009, 19:17

Re: MvK Monokl

Beitrag von wehkah »

Sieht spanned aus! Für mich ist das allerdings schon meisterhaft und nicht mehr nachvollziehbar :)

Falls Du Zuarbeit bei den GUI Elementen brauchst, kann ich gern helfen!

Beste Grüße und guten Rutsch!
T
MvKeinen
meister
Beiträge: 168
Registriert: 10. August 2006, 14:06
Wohnort: Berlin

Re: MvK Monokl

Beitrag von MvKeinen »

wehkah hat geschrieben:Sieht spanned aus! Für mich ist das allerdings schon meisterhaft und nicht mehr nachvollziehbar :)

Falls Du Zuarbeit bei den GUI Elementen brauchst, kann ich gern helfen!

Beste Grüße und guten Rutsch!
T
Vielen Dank!

Ich behalte das im Hinterkopf, allerdings ist es in der jetzigen Phase wichtig sich nicht zu sehr mit gestalterischen Dingen aufzuhalten, denn das würde sehr viel Zeit benötigen und ausserdem kann ich die Rahmenbedingungen für Symbole, fonts und Farben erst festlegen wenn das System fertig ist.

im Nächsten Video kann man schon ein paar neue Techniken erkennen. Es gibt die Möglichkeit ein und dieselbe funktion an mehreren Stellen des Displays zu editieren. In Verbindung mit meiner Version der "Stacked Macro" Funktionalität sind so verschiedene Übersichten möglich. Weiterhin sieht man auch die Animation von Audiosignalen und die Drag and Drop funktionalität.

https://vimeo.com/84515095
Reaktor Befürworter
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MvK Monokl

Beitrag von herw »

Ok - zunächst mal: das sieht SUPER aus und wirkt richtig elegant, flüssig und gut überschaubar. Die Fenstertechnik scheint nun völlig ausgereift, mittlerweile steige ich auch durch, was passiert.
Die Verknüpfung der Modulationen mit den Zielen ist völlig logisch und auch ohne Kabel ;) für mich einsichtig und entspricht der Funktionalität von MASSIVE.
Ich nehme mal an, dass die Module auch mittlerweile Audiosignale erzeugen?

Die Haptick erinnert mich sehr an lemur. Vielleicht solltest du darüber nachdenken, ob man die Fader und Schalter nicht der Optik von lemur anpasst, dann könnte man das ganze System auch vom iPad aus steuern, was ich mittlerweile äußerst praktisch finde. Das iPad ist wesentlich intuitiver als die Maus in Reaktor.

ciao herw
MvKeinen
meister
Beiträge: 168
Registriert: 10. August 2006, 14:06
Wohnort: Berlin

Re: MvK Monokl

Beitrag von MvKeinen »

Vielen Dank fürs Ansehen! :-)

Die Audiosignale die ich bisher habe sind die von den beiden LFOs und ENVs. Die werden mit der Methode die ich am Anfang des Threads beschrieben (erster upload) aus der Audiozelle geführt und in der Displayeventzelle zur Darstellung aufbereitet. Dort habe ich nun im Gegensatz zu meiner ganz alten Version eine Struktur gebaut die viel effizienter ist was zur Folge hat, dass sich ungeachtet der Anzahl darzustellender Animationen (Modulationssignale) die Architektur nicht ändert. Das läuft über eine Art des "Oversamplings" allerdings nicht von der Audioclock, sondern der Displayclock.

Das lässt mich natürlich auch über das "richtige" Oversampling nachdenken. Da mein system Automatisch erkennt wieviele LFOs, ENVs usw. "angemeldet" werden würde es der Struktur der großen Audiozelle guttun wenn diese Modulationsquellen nur einmal vorhanden sind dafür aber mehrere Male pro Audioclock berechnet werden.

Da muss ich jetzt ne folgenschwere Entscheidung treffen, weil ich jetzt dabei bin die Architektur der Audiozelle festzulegen.

Dazu hab ich mal ein Beispielensemble gemacht in dem es 2 Audiocorezellen gibt.

Die erste "oversampled" enthält einen LFO der 20mal pro Audioclock berechnet wird.
Die zweite "normal" enthält 20 LFOs die 1mal pro Audioclock berechnet werden.
overS.jpg
betrachtet man nun den CPU-load des Ensembles sieht man, dass die Corezelle "normal" (rechts unten untere Abbildung) mehr CPU verbraucht als die "oversampled"
das Problem steckt natürlich in dem A to E perm welches den Iterator triggert.
overSstruc.jpg
Wenn man nun das Oversampling in diesem Ensemble ausschaltet (Löschen der Eventleitungen die in die obere Audiozelle führen) sieht man, dass die Normalversion viel weniger CPU verbraucht.

Nun ist das aber nicht der Weisheit letzter Schluss, denn:

1. Werden in meinem "Endprodukt" niemals so viele Audiosignale herausgeführt da alles innerhalb der Audiocelle passiert.
2. Die Anzahl der Events pro Audioclock muss lediglich der maximalen Anzahl gleichförmiger Strukturen entsprechen und ist daher niemals 20. Wenn ich also 6 LFOs, 3 Sequenzer und 5 Envelopes habe brauche ich 6 Events pro Audioclock

Die Anzahl der Events pro Audioclock (und damit der CPU-load des "A to E perm") vergrößert sich also nicht wenn ich im Bau der großen Audiozelle fortschreite. Es könnte also sein, dass beim Erreichen eines gewissen Umfanges der Struktur der "Nachteil" des "A to E perm" verschwindet.

Meinungen und Erfahrungen dazu würden mich brennend interessieren.
oversmpLFO.zip
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Reaktor Befürworter
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MvK Monokl

Beitrag von herw »

sehr interessanter Ansatz - tolle Idee.

Meine Messungen (Maximalwerte) ergeben für mein MacBook pro (15 Zoll Ende 2008):
AtoE 4,0%
oversampled: 0,1%
normal 0,4%

Ich kann aber nicht sagen, ob die Anzeigen wirklich alles erfassen.

Für die LFOs und die Hüllkurven reichen doch niedrigere Taktfrequenzen (also zum Beispiel 400Hz). D.h., wenn du die AtoE-Zelle nicht mit der SR sondern der CR fütterst, reduziert sich der CPU-Verbrauch drastisch (auf 0,1%). Du musst natürlich dann die Stufen innerhalb der LFO-Zelle erhöhen, also nicht durch SR.R sondern durch CR dividieren.
Auch innerhalb der AudioCoreCell kannst du den CPU-Verbrauch auf Null senken, wenn du eine reduzierte Taktfrequenz anstelle der SR.C verwendest (kommt im Ensemble MONARK zur Anwendung)!

ciao herw
MvKeinen
meister
Beiträge: 168
Registriert: 10. August 2006, 14:06
Wohnort: Berlin

Re: MvK Monokl

Beitrag von MvKeinen »

Ja, die CR ist natürlich ne gute Lösung. Ich möchte allerdings auch LFOs haben die wirklich schnell werden und in den Audiobereich gehen. Wenn möglich 100-200Hz.

Trozdem kann es sein, dass die CR reicht. Die kann man ja auch höher setzen damit es genug "Samples" pro Wellendurchgang gibt.

da komm ich aber auf ein etwas witziges Problem :-)

ich habe Primary verlernt :-) ich brauche teilweise viel zu lange bis ich ein Primarymodul finde. Auch gehen einige Neuerungen von Reaktor komplett an mir vorbei. Wie das mit den Samplern und den Samplemaps. Witzig deshalb, weil ich zu anfangszeiten von Core nur Primary kannte und Core gehasst habe :-)

Bezüglich der CR bedeutet das, dass ich keine Ahnung habe was sich da geändert hat. Wird die gewählte CR-Frequenz mit dem Ensemble gespeichert?
Kann man dem User "verbieten" die CR herunterzusetzen?
bzw. ist die CR im "Play-mode" unveränderbar?

das probier ich jetzt mal alles.
Reaktor Befürworter
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MvK Monokl

Beitrag von herw »

MvKeinen hat geschrieben:[…]
betrachtet man nun den CPU-load des Ensembles sieht man, dass die Corezelle "normal" (rechts unten untere Abbildung) mehr CPU verbraucht als die "oversampled"
das Problem steckt natürlich in dem A to E perm welches den Iterator triggert.
overSstruc.jpg
Wenn man nun das Oversampling in diesem Ensemble ausschaltet (Löschen der Eventleitungen die in die obere Audiozelle führen) sieht man, dass die Normalversion viel weniger CPU verbraucht.

[…]
? Das kann ich überhaupt nicht bestätigen; der CPU-Verbrauch bleibt gleich.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MvK Monokl

Beitrag von herw »

Hallo D,
wieso unterschreibst du eigentlich mal mit T mal mit D, oder ist es das sächsische T? ;) . Wir sind ohnehin alle bei NSA schon aufgefallen.

Scherz beiseite, ich denke, du solltest mal ausprobieren, wie das AtoE perm Modul CPU-mäßig ausschlägt, wenn du Frequenz-Modulationen zwischen zwei Oszillatoren verarbeiten musst.
Probleme könnte es auch geben, wenn es auf die Reihenfolge der Module innerhalb der asynchronen Taktungen ankommt. Es kann natürlich sein, dass das für dein Ensemble nicht wichtig ist. An der Reihenfolge haben Gerald (krümelmonster) und ich uns schon Jahre immer wieder die Zähne ausgebissen.

ciao herw

PS: Gruß an NSA ;)
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MvK Monokl

Beitrag von herw »

Ich habe übrigens mal deinen Gedanken, die ganze Audio-Verarbeitung in eine einzige CoreCell zu packen aufgegriffen. Ich habe einen sehr kleinen modular gebaut, dessen jeweilige Module ihre Daten in ein gemeinsames Array schicken. Die Module greifen sternförmig auf das Array zu, was aber eigentlich keinen Unterschied macht. Gegenseitige Modulation erfolgt dann, indem man die Eingänge über einen Index befüttert. Ich habe das mal sehr systematisch vor einigen Jahren mit Gerald durchgecheckt. Für einfache Anwendungen wie meinem Modular ist die Reihenfolge, wie dann die Module während eines SampleRate Ticks agieren nicht so sehr erheblich. Gerald musste dagegen in seinem Ensemble wissen, in welcher Reihenfolge jegliche Rechnungen während desselben Ticks erfolgen. Ein Problem, das sich, solange es in REAKTOR noch kein (planbares) order-Module in core gibt, nicht lösen lässt. Auch event loops könnten auftreten, so dass REAKTOR gezwungen ist, ein Z^-1 Modul einzufügen.
Das ist jetzt mittlerweile meiner fünfter grundsätzlicher Ansatz für den Modular, wenn ich alle acht Jahre zusammen zähle.
Mich beeindruckt der einfache Zugriff auf das Array. Die Ansätze in primary funktionieren zwar perfekt, aber der ganze Aufwand, vor allem wenn man das Ensemble ändern möchte, hat mich schon immer geärgert. Ein Alternative sind shared AudioTables. Aber die sind viel zu CPU intensiv.

ciao herw
MvKeinen
meister
Beiträge: 168
Registriert: 10. August 2006, 14:06
Wohnort: Berlin

Re: MvK Monokl

Beitrag von MvKeinen »

Ich bin in letzter zeit mit der Doku nicht hinterhergekommen. Hatte so viel zu tun mit der integration der Modmatrix und der Modquellen, die jetzt alle so funktionieren, dass ich eine variable Anzahl von LFOs und ENVs haben kann ohne die Struktur zu ändern.

hier ein kleines Video: (gelegentliche audioglitches kommen wohl von der Youtube encodierung)

http://www.youtube.com/watch?v=lNomqEXTfvQ

demnächst mache ich ein Video mit Kommentaren.

Ich versuche auch demnächst meine Lösung für das Oversampling der Modulationsquellen hier darzustellen.

Gruss
Reaktor Befürworter
MvKeinen
meister
Beiträge: 168
Registriert: 10. August 2006, 14:06
Wohnort: Berlin

Re: MvK Monokl

Beitrag von MvKeinen »

hier ist ne playlist wo ich langsam einen beat aufbaue

fullscreen 1080 einstellen

http://www.youtube.com/watch?v=VCXXhVbk ... iaYg3gNHJm
Reaktor Befürworter
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MvK Monokl

Beitrag von herw »

Hallo David,
irgendwelche Neuigkeiten zu deinem Projekt? ::kaffee::

ciao herw
MvKeinen
meister
Beiträge: 168
Registriert: 10. August 2006, 14:06
Wohnort: Berlin

Re: MvK Monokl

Beitrag von MvKeinen »

ich bin noch sehr gut weitergekommen. Das system ist jetzt stabiler und klingt auch schon. Dann aber musste ich einige Wochen pause machen, Gerade weil ich mir nicht mehr sicher war wie das mit der Zukunft von Reaktor aussieht und weil ich auch wieder mehr musik machen wollte. Ich brauch zB multicoresupport von Reaktor ganz einfach. 6Stimmig läuft mein System (ist bisher nur der halbe synth) auf 24% (Prä-Sandy-Bridge i7). Für meinen Liveact brauch ich 16-20 Stimmen und noch Platz für Gesangsverwurstelungen. Mehrere Instanzen geht nicht, weil ich ja neben den modulationen der Einzelsynths noch eine "globale Modulationsmatrix" habe die alle 6 bzw 20 Synths steuern kann.

Jetzt ist ja ein update da und erste Spuren von einer Hardwareintegration zu sehen die ich mir schon seit jahren wünsche. Ich hoffe inständig, dass das HW-control Modul auch die Maschine HW ansteuern kann. Dazu will ich noch Multidisplays die automatisch auf den beiden Maschine Screens gezeigt werden.

Ich bin da aber immernoch guter Dinge.

Der Plan ist jetzt das ganze System nochmal neu aufzusetzen (glücklicherweise sind seit dem letzten Majorupdate jetzt ALLE Eckpfeiler des systems variabel) mit einer sehr abgespeckten Version des synths, der aber immernoch alle Funktionalitäten des Interface-Frameworks benötigt. Glücklicherweise hab ich bevor ich schluss gemacht habe ne vollständige Doku erstellt, die zwar nur ich verstehe, die mir aber den Wiedereinstieg sehr erleichtern wird.

Daher passt es jetzt ganz gut, dass Reaktor geupdated wurde (Ich find die Neuerungen super, bin aber etwas enttäuscht über die fehlende Pflege von Core)

Mouseover:
genial, auch dass PX/PY bei mouseover senden können. Das ermöglicht in meinem System, dass Funktionsgruppen exklusiv in den Multidisplays "gerendert" werden können und mit meinem Textmodul auch Tutorials abhängig von der Mausposition.

Automation:
Kann sein, dass ich hiermit den Umweg über knobs für die Automation ungehen kann. Das würde meine Primary-Struktur ziemlich verkleinern. Da muss ich mal schauen. ::kaffee::
Reaktor Befürworter
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MvK Monokl

Beitrag von herw »

nun ja ich vermute mal, dass ein REAKTOR 6 wohl in core deutliche Verbesserungen bieten muss.
Das dauert aber wohl, multicore ist auch Pflicht. D.h. R.5.9.2 war „nur” Produktpflege, aber für ein micro-Update doch ordentlich. Ich durfte schon länger damit arbeiten und es ist super stabil und hat viele bugs beseitigt.
Eventmanager
synth doctor
Beiträge: 271
Registriert: 25. Juni 2013, 15:26

Re: MvK Monokl

Beitrag von Eventmanager »

herw hat geschrieben:nun ja ich vermute mal, dass ein REAKTOR 6 wohl in core deutliche Verbesserungen bieten muss.
Das dauert aber wohl, multicore ist auch Pflicht.....
Muss es das? Mir würde die Beseitigung mehr als 15jähriger GUI-Katastrofen erstmal reichen. Das NI nicht ungeizig mit neuen Modulen ist, haben sie ja von 5 bis 5.92 ausreichend klargestellt.

- ein verbessertes sampler-modul (insbesondere des anachronistschen map/access "modules")
- workflow-erleichterungen (defaults for modules - load as mono, port x has y-constant, a in port....) better navigation/snap-reorganize (tabbing)... and stuff like this
- the possibility to make enesmbles as VSTi (maybe for an extra price, as reaktor-XXL-version)

Mehr oder minder Kleinigkeiten (zumindest vom Implementierungsaufwand), die uns aber die größten Nervereien abnehmen. Das wäre eine 6 allemal wert. Produktpflege in Form von neuen Modulen, Verbesserungen der Verbesserungen, aufbohren von Core.... nun, da haben sie die nächsten 15 Jahre zeit, bis zu V7.

[--- dieser Passus wurde von mir gelöscht; bitte Nettiquette beachten (herw) ---]
Antworten