Deutsches Reaktor Forum

Zukunftsträume und Spinnereien - der Titel sagt schon alles aus.

Ich möchte mal eine Thread anregen, der sich mit einem futuristischen Produkt nach REAKTOR 5.9.9 auseinandersetzt.
Wie könnte ein Nachfolgeprodukt aussehen? Ich möchte hier witzige, einfallsreiche, interessante Ideen und Absurditäten sehen. Einzige Bedingung: es soll sich immer noch um eine (im Wesentlichen) grafisch orientierte Programmierumgebung handeln, die als Hauptziel das Erzeugen von Geräuschen und Tönen hat.
Ich habe hier in einigen Beiträgen auch interessante Bilddarstellungen gesehen. D.h. es ist auch von starkem Interesse zu erfahren, wie eine Programmierebene und eine Panelebene aussehen könnten, also Photoshop-Anwender an die Arbeit, es sollte auch was für's Auge dabeisein, Skizzen, Grafiken, etc. .
Was ich will, sind ausgefallene Utopien, egal ob sie einfach oder schwierig realisierbar sein sollten (auch Hardware Kombinationen), nur müssen sie anregend sein, darüber nachzudenken und zu diskutieren, mit anderen Worten innovativ. Es muss nicht immer der große radikale Bogen sein, auch Kleinigkeiten sind erwünscht.
Na dann mal los (REAKTOR-Stammtisch-Spinnereien).

ciao herw

PS: wenn gute Beiträge dabei sein sollten, dann reiche ich sie selbstverständlich „nach oben” weiter
Motto: wir sind die Ideenschmiede und NI arbeitet für uns (schön wär's)

Hej Herw,

das klingt ja super wobei ich an der Reaktor Oberfläche nichts ändern würde. Eher an Workflow und Möglichkeiten. Z.Bsp wäre das Nutzen von gebastelten Effekten in GuitarRig nice, wenn man eine registrierte Reaktor Version besitzt. Vom Panel her wären Multiknobs / Grafiken die sich überlagern nice, Stichwort Grafiklayer. Scripting ala Max oder PD. Hardwarseitig kann ich mir eigentlich nur sowas wie den NordModular vorstellen. Als Partner von Maschine bestimmt witzig, also mit eigener CPU und so. Die Wiederbelebung von Core wäre sicher auch vielen recht.

Eine PCI-E Soundkarte von NI mit direkter DSP unterstützung der NI Synths ala Powercore.

Gruß&Sonne

wehkah hat geschrieben:[...]Die Wiederbelebung von Core wäre sicher auch vielen recht.
[...]

Du meintest sicherlich Kore.

herw hat geschrieben:

wehkah hat geschrieben:[...]Die Wiederbelebung von Core wäre sicher auch vielen recht.
[...]

Du meintest sicherlich Kore.

Ach ja die Angewohnheit

Was mir noch einfällt wäre:

Ein interner Eventdebugger und eine automatische Korrekturfunktion bei Stereo/Mono Kombinationen per Rechts-Klick.
Numeric Readout mit Stimmenselektor direkt in der Modulpref, einfach aber nützlich.
Eigene Schriftarten für das Panel. Da würden sich viele Grafikfitzeleien erübrigen. Die Schriftzüge könnten im Usermode dann als Grafik angezeigt werden, quasi aus einem einem Render-Chache, als normale Multipictures Module die sich durch Ebenen zusammensetzen oder als eine simple komplette Hintergrundgrafik. Und natürlich für Valueanzeigen bei Knobs/Slidern!
Macroreglerleiste mit auswählbarer Regleranzahl (4/8/16/32), mit Midimapping.
Copy&Paste zwischen einzelnen Reaktor-Instanzen.

noch nicht utopisch genug

Ist zwar jetzt nicht utopisch oder so (zumindest so lang man nicht verlangt das NI das auch umsetzt ) aber MultiTouch support und spezielle Panelelemente dafür wären zumindest mal eine echte Neuerung. Und Ein- und Ausgänge die man auf der Oberfläche mit einem Kabel verbinden kann damit der herw nicht mehr soviel basteln muss!

sellotape hat geschrieben:Ist zwar jetzt nicht utopisch oder so (zumindest so lang man nicht verlangt das NI das auch umsetzt ) aber MultiTouch support und spezielle Panelelemente dafür wären zumindest mal eine echte Neuerung. Und Ein- und Ausgänge die man auf der Oberfläche mit einem Kabel verbinden kann damit der herw nicht mehr soviel basteln muss!

Das sind zwei Vorschläge; ich gehe mal auf den ersten ein: MultiTouch ist keine Utopie mehr, aber NI scheint dort die Entwicklung zu verschlafen. Es gibt lediglich die iMaschine. Meiner Ansicht nach müsste NI auch für den REAKTOR-Bereich eine Kopplung von Programm und Hardware herstellen, sei es durch eigene Hardware (spezielle programmierbare Reglerpulte) oder Touchscreens (iPad). Natürlich gibt es die Möglichkeit, mit diversen Drittanbietern, REAKTOR über einen Touchscreen anzusteuern. Etwas REAKTOR-näher wäre aber wünschenswert.
In meinen Augen ist das keine Utopie, sondern umgekehrt eine Nachlässigkeit, dies nicht anzubieten.
herw

herw hat geschrieben:In meinen Augen ist das keine Utopie, sondern umgekehrt eine Nachlässigkeit, dies nicht anzubieten.

Absolut! Selbst die Implementierung sollte keine Herausforderung sein. Ich arbeite schon seit 2-3 Jahren mit einem 23" MultiTouchScreen und Usine. Für die Hardwareanbindung ist ja der Treiber zuständig. Reaktor müsste eigentlich nur mehrere "mouseclicks" gleichzeitig zulassen und das kann jede besch... Smartphone App. Aber was Controller angeht bin ich über die technische Entwicklung echt enttäuscht! Es gibt nur wirklich wenige OSC-Controller für Wucherpreise und es gibt auch nicht wirklich viele Programme die OSC unterstützen. Und MIDI mit seinen 7Bit Reglern ist einfach nicht mehr Zeitgemäß. Ich glaub da kann jeder Reaktoruser ein Lied von singen.

Der Titel könnte vermuten lassen, dass ich meinen modular x gerne von NI unterstützt haben möchte; das ist nicht der Fall. Ich möchte hingegen, dass man für das Panel eine zusätzliche übergeordnete Hyper-Ebene erstellen kann: Die Abbildung stellt nur einen ersten Ansatz dar. Man erkennt keine Bedienelemente mehr sondern nur noch Signalverknüpfungen.
Die Abbildung ist sehr, sehr einfach gehalten, sollte aber beliebig erweitert werden können. Ich stelle mir ein dreidimensionales (!) Netzwerk auch mit halbtransparenten Objekten vor, die es ermöglichen, grobe Strukturen zu errichten und zwar ohne Rücksicht darauf, ob es sich um Event- Audio, poly- oder monophone Signale handelt. Also bitte einen geordneten räumlichen Dschungel vorstellen. Ich hätte statt eines Oszillators auch allgemeinere Begriffe nehmen können, wie Klangerzeuger, Hüllkurve, etc..
Der Benutzer drückt durch die Pfeile nur aus, dass ein bestimmtes Modul einen Einfluss auf ein anderes ausübt, sei es modulierend oder Signal zuführend.
Nun kommt der Clou: klickt man auf ein solches Modul, dann kann man zunächst seine Art wählen (spezieller Oszillator, spezielle Hüllkurve etc.). Das spezielle Modul bietet nun in einem aufgeblendeten Fenster verschiedene Ein- und Ausgänge an, die den Pfeilenden zugeordnet werden. Das Programm macht dabei für den ungeübten Programmierer selbstständig sinnvolle Vorschläge, die aber natürlich änderbar sind. Beispielsweise können die Signale der Module Midi und ADSR zum oberen Oszillator vom Programm zunächst sinnvoll automatisch einem internen Mixer zugeordnet werden und dann den Pitch beeinflussen. Das Signal des unteren Oszillators kann etwa der Frequenz- aber auch der Pulsweiten-Modulation dienen. Das Modul erweitert bei weiteren Signalzuweisungen seine Anschluss- und Einspeisungsmöglichkeiten.
Dabei werden auch Regler (mit Positionsvorschlag) angeboten. Da dies bei starker Erweiterung (zusätzliche automatische Mixer etc.) unübersichtlich würde, ist es sinnvoll, für den praktischen Gebrauch spezielle Regler, die man bedienen möchte, auszuwählen und einer Hardware oder einem extra Bedienfenster (ähnlich dem Konzept in KORE 2) zuzuweisen.
Natürlich ist ein solches intelligentes Vorschlagssystem wohl revolutionär, aber warum nicht in eine solche Richtung denken: vergleicht man zum Beispiel Textverarbeitungsprogramme oder SMS-Schreibereien, die Texte sinnvoll ergänzen oder Sound- und Stilrichtungsauswahl bei Programmen wie Garageband etc., dann ist das nicht unrealistisch.
Wie soll das gehen? Nun es muss ein für den Benutzer nicht sichtbares Bussystem, besser Netzwerk geben, das jegliche Informationen adressieren kann und auch deren Art (Event, Audio) selbstständig erkennt. D.h. das Programm muss den Datenfluss ständig im Griff haben (welche Signalart, Quelle, Ziel, Polyphonie, etc.) und ihn für fortgeschrittene Programmierer auch bereitstellen.
Schaut man in die Properties einzelner Bedienelemente von REAKTOR, dann haben diese ja schon interne Identifikationsnummern; also warum nutzt man sie nicht und erweitert die Möglichkeiten?
Eine Normierung der Ein- und Ausgänge ist bei diesem System ein Muss. Trotzdem soll der Benutzer natürlich weiterhin die Möglichkeit haben, selbst entsprechende Module herzustellen.
Was ist der Vorteil eines solchen Systems: auch Neulinge werden durch die einfache Hyper-Ebene und durch die (sinnvollen Vorschläge) des Programms an die grafische Programmierung herangeführt.
Es muss ausgeklügelte Debugging-Möglichkeiten geben: man „fliegt” einem Event in dem 3D-Netz hinterher und kann so seinen Verlauf und seine Werte verfolgen (action debugging ). Man kann bestimmte Teilbereiche des Netzwerks besonders hervorheben und durch einen Algorithmus in einem vereinfachten 2D-Netzwerk darstellen, wenn dies gewünscht ist..... ich höre jetzt mal auf, mir fällt aber bestimmt noch viel mehr ein.


ciao herw

PS: die in REAKTOR angeboten Macros „building blocks” und „classic modular” sind ein solcher (eingestaubter) Ansatz, modular x geht im (verstaubten R5) etwas weiter, stößt aber zwangsläufig an die Grenzen des Machbaren.

Deine Idee ist wirklich klasse! Das ist bei der http://www.reactable.com/ Software so gelöst. Björk hat das mal live benutzt und das sah sehr einfach aus.

So eine Technik würde es vielen sehr erleichtern den Zugang zu finden. Deine GUI Überlegungen kommen eben daher, dass Du eine Anwendung hast wo soetwas durchaus Sinn machen würde. Darauf kommt man eben nicht beim Programmieren von Reaktor sondern beim benutzen. Der Workflow könnte um vieles besser sein, vorallem nach sovielen Jahren Entwicklungsarbeit.

Wie ich bereits mehrfach im NI Forum und hier auch erwähnt habe, wären auch wirklich gute Tutorials/Bücher nötig. Die ganzen Videos und Tutorial Schnipsel im Netz nerven. Eventuell könnte NI eine Modulhilfe nach dem Vorbild von Max integrieren (nich nur die Infoview).

cheers
T

Erstmal das Übliche:

Sampler_modul das per Snap auch gleich andere Multisamples/Monolithen lädt (ausserdem Import von Kontakt/Maschine-Libs)
Verwaltungstool für Snaps (Batchfunktionen für verschieben/kopieren/umbenennen/randomize....) ; temporäres Snap-Change-Memory im Host (habe mehere Snaps geändert aber nicht gesaved, diese Instanz in diesem Song merkt sich trotzdem alle Änderungen "temporär" bis ich explizit auf "sanp-back" klicke.
Andere Lösung für StackedMacros; Hierarchie für Panel-Priorität für einzelne Elemente frei wählbar
Multiple Polyphonie-settings für Macros
Shortcut-Modul: cmd, alt, ctrl... und sämtliche Combis plus maus oder alpha-numerics können als Trigger, Modi-Umschalter oder dynamische Funktionsswitcher (nächstes Multisample, nächster Switch-In...) verwendet werden
Keine Altlasten-Abwärtskompatibilität, nur einen Legacy-mode, eine 2te exe/dmg für für alte Ensembles. Automatisches Importieren so weit möglich, (mit Optionen - Ersetze Stacked Macros mit "Fenstermodul A, B oder C", Kennung aller fraglichen Macros bei denen automtisches Konvertieren zu eigenmächtig wäre... Gibts keine Kennungen mehr: "Save as V6" und nun können wir das deutlich schlankere und schnellere pure V6 nutzen.
(von mir aus ne teurere) Creator-Version, die es ermöglicht Ensembles als "Player" zu erstellen.



Verdrahtungs "Batch" - ich definiere einen oder mehrere Ur-OUT(s) und die finalen IN(s). Bei eindeutigen Signalwegen wars das, Reaktor produziert alle Zwischen In-Outs selbstständig und sinnvoll gelabelt.Bei uneindeutigen Wegen kommt zum einen Herws Vorschlag und ne "Stempel"-Funktion ins Spiel: Mein Endziel sind bspw. die ADSR-IN einer Hüllkurve. Ich gummibande alle 4 und sage "verbinde mit..." jetzt hangel ich mich in Herws Überischts-Matrix bis zu den Ur-Bedienknobs, Reaktor erzeugt alle nötigen In/Outs und verkabelt selbstständig alle die ziemlich eindeutig sind, bei fraglichen Verbindungen stehen nur die In/outs unverdrahtet. In der Matrix sehe ich die fraglichen Macros und gelange per One-Klick dorthin und verdrahte manuell. Gefällt mir ein Namensvorschlag (In/out Reihenfolge) nicht, kann ich irgendwo in der Kette einen Port umbenennen und sag "für alle" und schwupps sind alle Ports entsprechend gelabelt. Ferner kann ich irgendwo mehrere Ports selektieren und ne realtive Reihenfolge festlegen, wiederum "für alle" sagen und statt ADSR habe ich jetzt überall sauber DRAS (oder eben was Sinnigeres;).

Stempel-Batch - ich habe nen Haufen identischer Viel-Level-Mega-Macros. Tief verschachtelt nehme ich 3,4 kleine Änderungen vor, die ich gerne ebenfalls in allen anderen "Megas" hätte. Ich gehe zur obersten Mega-Ebene sage "Änderungen übernehmen für" und klicke die Klone an, sage "Hier", voila!.

"Maschine-Edit-Integration" Meine 8x16 Pads könnten meine Lieblingsmodule einfügen (mit Solo als poly, sonst monophon) oder shortys zu structuren bookmarken...
Mittels Scene, Pattern, Pad... liessen sich Hunderte Arbeitserleichterer definieren...

Multi-Ins - (verlangt Teamwork mit Host-Bauern;) CPU intensive FX/Veredler könnten als "Multi-Dry/Wet" einmal berechnet werden, ich definiere nur Anzahl "intern-Mixer-Ins" mit bspw. Low/High-Passern und anderen Routing-Faxen, speziellen Abgriffspunkten... dann könnte ich sehr individuell nur bestimmte Aspekte für die jeweiligen Tracks prozessieren lassen und das für nen Bruchteil der CPU-Kosten mehrerer Instanzen.

Könnte noch stundenlang weitermachen, frustriert nur, wenn nix davon in Angriff genommen wird:-(