REAKTOR 6 - Wünsche

[magneton]

Funktioniert das möglicherweise auch bei 5.12-er Ensembles, um sie mit 5.11 zu öffnen???

leider nicht - bei MF war das ensemble in eine ausführbare datei eingebettet, und das konnte man extrahieren. das ensemble selbst war mit der aktuellen reaktor version erstellt.

[Triton]

Kabelbinder wären klasse. Stell ich mir so vor, dass man einen weiteren Ein-/Ausgangstyp (eine Divide- bzw. Merge-Station) mit einer Anzahlsangabe dazu baut, wo dann mehrere (die Zahl eben) Werte raus-/reingehen. Dann legt man ein dickes Kabel (neuer Verbindungstyp) eine Ebene höher und am anderen Ende wird das Array komplett empfangen und wieder in einzelne Kabel auseinanderdividiert. Die Anzahlen müssen halt übereinstimmen. Verschachtelt wäre noch abgefahrener. Also Kabel mit Kabeln mit Kabeln drin, etc.

Alternativ: Drahtharfen-Autoconnect. Mit ein paar Klicks x Kabel von a nach b schieben.

Irgendwie geartete for next Schleifen (schwierige Sache) (in einer Voice).

Globale Funktions-Cells (wenn man die zentral ändert, ändern sich alle verbauten. Wie eine Funktion in Programmiersprachen.)

[herw]

Kabelbinder wären klasse. Stell ich mir so vor, dass man einen weiteren Ein-/Ausgangstyp (eine Divide- bzw. Merge-Station) mit einer Anzahlsangabe dazu baut, wo dann mehrere (die Zahl eben) Werte raus-/reingehen. Dann legt man ein dickes Kabel (neuer Verbindungstyp) eine Ebene höher und am anderen Ende wird das Array komplett empfangen und wieder in einzelne Kabel auseinanderdividiert. Die Anzahlen müssen halt übereinstimmen. Verschachtelt wäre noch abgefahrener. Also Kabel mit Kabeln mit Kabeln drin, etc.

Alternativ: Drahtharfen-Autoconnect. Mit ein paar Klicks x Kabel von a nach b schieben.

[...]

jaaaaaa - ich kann dir nur raten, mal in vierzehn Tagen einen langen und tiefen Blick in REAKTOR PRISM zu werfen!
Drahtharfen sind eine schreckliche Vorstellung und gehören endlich auf den Programmiermüll!

ciao herw

[Triton]

jaaaaaa - ich kann dir nur raten, mal in vierzehn Tagen einen langen und tiefen Blick in REAKTOR PRISM zu werfen!
Drahtharfen sind eine schreckliche Vorstellung und gehören endlich auf den Programmiermüll!

ciao herw

Das Teil klingt ziemlich klasse. Zumindest die Demo-Tracks. Sieht auch übersichtlich aus. Den Apparat wird man in Zukunft gewiss öfter in Produktionen hören.

Allerdings hab ich mir gerade erst Komplete 6 gekauft (im Juno das Schnapp-Update) und werd 7 wohl überspringen (und vom fm9 träumen).

[herw]

jaaaaaa - ich kann dir nur raten, mal in vierzehn Tagen einen langen und tiefen Blick in REAKTOR PRISM zu werfen!
Drahtharfen sind eine schreckliche Vorstellung und gehören endlich auf den Programmiermüll!

ciao herw

Das Teil klingt ziemlich klasse. Zumindest die Demo-Tracks. Sieht auch übersichtlich aus. Den Apparat wird man in Zukunft gewiss öfter in Produktionen hören.

Allerdings hab ich mir gerade erst Komplete 6 gekauft (im Juno das Schnapp-Update) und werd 7 wohl überspringen (und vom fm9 träumen).

ja, das ist ein bisschen ärgerlich; andererseits sind die ganzen goodies plus 50€ Gutschein auch nicht zu verachten.
Übrigens glaube ich nicht an ein FM9; was soll da noch kommen? Ich denke, dass PRISM die Erweiterung ist.

ciao herw

[Triton]

]ja, das ist ein bisschen ärgerlich; andererseits sind die ganzen goodies plus 50€ Gutschein auch nicht zu verachten.
Übrigens glaube ich nicht an ein FM9; was soll da noch kommen? Ich denke, dass PRISM die Erweiterung ist.

Ist eine Art Sample-Library, die man mit Komplete 7 bekommt. Vielleicht werd ich irgendwann doch noch schwach. Beim fm9 wär ich auch ratlos. Mehr Operatoren bringt nix, Filter vor einem Carrier sind seltsam, Mutate wie im Absynth kann ich mir auch nicht richtig vorstellen. Hmm. Aber das Ende der Fahnenstange bei fm kann doch noch nicht erreicht sein. fm-Resynthese vielleicht (Spektrum nehmen, umrechnen, rechnerisch Hölle gewiss) oder morphbare Wellenformen in den Operatoren oder dieses Soundüberblenden (Mischen der Operatorenmatrix) mit adsr/lfo in einem Sound. Geb's zu, wird schwierig.

[sternenkrieger]

die piano flut und und die sonst vollkommen belanglosen samplelibraries die bei komplete dabei sind, haben mir die entscheidung sehr leicht gemacht ..
viel cooler wäre es gewesen die libraries individuell auswählbar zu machen.
aber so hab ich da kein bock drauf, für die kohlen die ich mir da spar hol ich mir jitter

[Triton]

Werd's auch sein lassen mit Komplete 7.

Hab noch einen dicken Wunsch für Reaktor 6: Biquad-Modul-Filter bzw. Butterworth-Filter-Module (oder aber noch chicer, die Cells deutlich beschleunigen). Ich geb's auf, Z-Plane-Filter mit den 2-Pol-Modulen nachbilden zu wollen, krieg die Koeffizienten einfach nicht raus.

Ah, und eine Palette FIR-Filter als Modul wär noch was. SinC- z.B.

[herw]

Werd's auch sein lassen mit Komplete 7.

Hab noch einen dicken Wunsch für Reaktor 6: Biquad-Modul-Filter bzw. Butterworth-Filter-Module (oder aber noch chicer, die Cells deutlich beschleunigen). Ich geb's auf, Z-Plane-Filter mit den 2-Pol-Modulen nachbilden zu wollen, krieg die Koeffizienten einfach nicht raus.

Ah, und eine Palette FIR-Filter als Modul wär noch was. SinC- z.B.

diesen download kennst du doch?
http://co.native-instruments.com/index. ... tchid=7769

der dazugehörige Artikel ist allerdings anspruchsvoll, die Filter aber sehr schön.

[MvKeinen]

einfacher wunsch für r6: Ein numeric readout das auch in der strukturansicht den Wert anzeigt..

[Triton]

]diesen download kennst du doch?
http://co.native-instruments.com/index. ... tchid=7769

der dazugehörige Artikel ist allerdings anspruchsvoll, die Filter aber sehr schön.

Hab mich tatsächlich mal da durchgehangelt, aber puh, das geht schon zur Sache. Gebaut hatt ich jedoch direkte splane-Filter, wovon er eher deutlich abrät. Nur sind die jetzt eh so monströs und umständlich einzustellen, dass ich sie selbst gar nicht benutzen mag.

Hoffe, dass NI Core mit R6 schneller kriegt (falls das überhaupt geht, Cellcode in Zwischensprache precompilieren oder so, nur ob das nicht den Workflow beeinträchtigt), die Modulfilter zocken Cells gerade bei vielen Voices frustrierend heftig ab.

Für Core hätt ich noch den Wunsch von Tastenshortcuts (z.B. Nummernblock "+" setzt Addierer) und logischen Operationen direkt auf den Bool-Variablen. Und die Möglichkeit, die derzeitigen Variablen eines Arrays mit dem Debug-Mode einzusehen. Ah, und bedarfsweise Einfärbung von Integer-Quickdingens bzw. von den Stellen, wo "teuer" Fließkomma<->Integer transformiert wird.

Wo ich mir nicht sicher bin, ob das nicht eine Eigenart des Reaktor etwas beschädigt (und vor allem schwer zu verwalten ist), wären halt regelrecht "Funktionen", also Core-Makros, die man ganz normal baut, die jedoch geklont bzw. einmal zentral in der Cell vorliegen und bei einer späteren inneren Änderung nicht aufwendig alle neukopiert und -verkabelt werden müssen. Oder aber so eine Art global Makro-Search and Replace, dann auch so richtig über mehrere Cells drüber (auch mt Vorsicht zu genießen, da kann man sich eine Struktur schnell mit zerhämmern, befürcht ich).

Grüssle

[KlangRaum]

Wo ich mir nicht sicher bin, ob das nicht eine Eigenart des Reaktor etwas beschädigt (und vor allem schwer zu verwalten ist), wären halt regelrecht "Funktionen", also Core-Makros, die man ganz normal baut, die jedoch geklont bzw. einmal zentral in der Cell vorliegen und bei einer späteren inneren Änderung nicht aufwendig alle neukopiert und -verkabelt werden müssen. Oder aber so eine Art global Makro-Search and Replace, dann auch so richtig über mehrere Cells drüber (auch mt Vorsicht zu genießen, da kann man sich eine Struktur schnell mit zerhämmern, befürcht ich).

Wünsche ich mir auch - also ein Parent-Macro (egal ob Core oder Primary) das Änderungen an seine Child-Kopien weitergibt

[herw]

Wo ich mir nicht sicher bin, ob das nicht eine Eigenart des Reaktor etwas beschädigt (und vor allem schwer zu verwalten ist), wären halt regelrecht "Funktionen", also Core-Makros, die man ganz normal baut, die jedoch geklont bzw. einmal zentral in der Cell vorliegen und bei einer späteren inneren Änderung nicht aufwendig alle neukopiert und -verkabelt werden müssen. Oder aber so eine Art global Makro-Search and Replace, dann auch so richtig über mehrere Cells drüber (auch mt Vorsicht zu genießen, da kann man sich eine Struktur schnell mit zerhämmern, befürcht ich).

Wünsche ich mir auch - also ein Parent-Macro (egal ob Core oder Primary) das Änderungen an seine Child-Kopien weitergibt

Ich denke, das ist so weit reichend, dass man REAKTOR neu erfinden muss, also ein sehr gravierender Eingriff in die Gesamtkonzeption.
Damit dies für uns User schnell geschieht, müsste neben der für uns sichtbaren Weiterentwicklung von REAKTOR 5 (was ja offenbar im Augenblick geschieht) schon das grundsätzliche Gerüst für uns unsichtbar geändert worden sein.
Ich meine mich erinnern zu können, dass bei der Vorstellung von R5.5 erwähnt wurde, dass sehr viel Code neu programmiert wurde. Aber ob das schon so weit geht, dass sogar solche Schmankerl möglich sind, steht leider in den Sternen. Die Stellenanzeige vor einigen Monaten deutete so etwas an; aber das ist jetzt wirklich Kaffeesatzleserei.

ciao herw

[Triton]

Die Core-Programmierer sind bestimmt auch am kräftig Spaß haben mit 64bit und Mehrkern-Parallelisierung. Stelle mir das heftig vor, weil bei jeder Änderung alle bisherigen Strukturen ja weiterfunktionieren müssen. Da wird wohl eher da der Blick draufliegen.

Noch'n vielleicht etwas überzogener Wunsch: Primary-FFT. so ein richtig fies optimiertes, in C geschriebenes, Primary-Modul (das dann wie EzFFT in eine Cell streamt oder gleich ganze Array-Blöcke schreibt) und z.B. auch 2048er Blöcke ermöglicht (dann matscht der Bass nicht so).

[MvKeinen]

Die Core-Programmierer sind bestimmt auch am kräftig Spaß haben mit 64bit und Mehrkern-Parallelisierung. Stelle mir das heftig vor, weil bei jeder Änderung alle bisherigen Strukturen ja weiterfunktionieren müssen. Da wird wohl eher da der Blick draufliegen.

dazu scheint mir dieser Artikel ziemlich interessant:

Zitat daraus:

Anders als bei allen bisherigen Computern nach der Von-Neumann-Architektur, die im Wesentlichen eine serielle Verarbeitung von Befehlen vorsieht, will Vishkin auf Seiten des Programmierers die "Immediate Concurrent Execution" (ICE) erreichen. Ein Programm kann dabei beliebig viele Befehle gleichzeitig geben, und auch ein Compiler soll dann nicht mehr notwendig sein, um diese in eine mehr oder weniger sinnvolle Reihenfolge zu bringen.

Wie diese Befehle dann möglichst gleichzeitig ausgeführt werden können, um eine hohe Rechenleistung zu erzielen, darum soll sich die Hardware kümmern. Bei einem Mehrkernsystem soll einer der Cores die anderen steuern. Bisher ist es genau umgekehrt: Die Software, in der Regel das Betriebssystem, verteilt die Arbeit an die Kerne. Das erzeugt auf Desktopsystemen, bei denen viele Programme gleichzeitig laufen, inzwischen solche Probleme, dass beispielsweise Intel und Microsoft für Windows 7 gemeinsam die Threadverwaltung gestalten mussten. Der Vorschlag, der Hardware mehr Kontrolle über die Lastverteilung zu geben, kam kürzlich auch von Microsoft.

http://www.golem.de/1101/81080.html