R6 - was ist wirklich neu?

[Eventmanager]

also mal abgesehen von dem Lego-Baukasten für wochenend-developer, blocks genannt, was ist für "deep-level-strippenzieher" besser geworden?

Sofern ich das überblicke, gibt es weder Verbesserungen im Bedienkomfort/Arbeitseffizenz, keine neuen Module, noch einen Sampler der sich moderner, als wie im frühen 19ten Jahrhundert, mappen/editieren lässt und ne echte null-punkt-loop/smooth funktion bietet. Mal ganz abgesehen davon das es noch immer unmöglich ist, autarke VST zu erzeugen (oder zumindest solche die im PLAYER laufen).

Also was ist wirklich verbessert worden?

Ich mein, früher oder später werde ich wohl upgraden, wahrscheinlich braucht es zur #7 auch wieder 12 Jahre und wenn zwischenzeitlich ne ähnliche Produktpflege wie bei R5 betrieben wird (ich sage nur das freie update zu R5.5; sine- und modalbank und die FFT-giveaways - vielen, vielen dank dafür) dann wird R6 wohl auch ne gute Investition, auch wenn momentan kein echter Zusatznutzen sichtbar ist.
Und auch wenn Bedienkomfort und GUI-Effizeienz echte Stiefkinder bei den Entwicklern sind, mit R 5.6 haben sie mit breadcrumb und enter-in-structure, zumindest mal guten Willen gezeigt. DIe Hoffnung stirbt zuletzt;-)

Also was ist neu (und was darf man im Laufe der Jahre so erwarten?).

[herw]

also mal abgesehen von dem Lego-Baukasten für wochenend-developer, blocks genannt, was ist für "deep-level-strippenzieher" besser geworden?

Sofern ich das überblicke, gibt es weder Verbesserungen im Bedienkomfort/Arbeitseffizenz, keine neuen Module, noch einen Sampler der sich moderner, als wie im frühen 19ten Jahrhundert, mappen/editieren lässt und ne echte null-punkt-loop/smooth funktion bietet. Mal ganz abgesehen davon das es noch immer unmöglich ist, autarke VST zu erzeugen (oder zumindest solche die im PLAYER laufen).

Also was ist wirklich verbessert worden?

Ich mein, früher oder später werde ich wohl upgraden, wahrscheinlich braucht es zur #7 auch wieder 12 Jahre und wenn zwischenzeitlich ne ähnliche Produktpflege wie bei R5 betrieben wird (ich sage nur das freie update zu R5.5; sine- und modalbank und die FFT-giveaways - vielen, vielen dank dafür) dann wird R6 wohl auch ne gute Investition, auch wenn momentan kein echter Zusatznutzen sichtbar ist.
Und auch wenn Bedienkomfort und GUI-Effizeienz echte Stiefkinder bei den Entwicklern sind, mit R 5.6 haben sie mit breadcrumb und enter-in-structure, zumindest mal guten Willen gezeigt. DIe Hoffnung stirbt zuletzt;-)

Also was ist neu (und was darf man im Laufe der Jahre so erwarten?).

längere Antwort:

vorweg; du wirst ohne R6 einfach in der user library abgehängt.
Natürlich ist es ärgerlich, wie ich auch schon andernorts beschrieben habe, wenn man 99€ für das update ausgibt und dann eventuell kurze Zeit später es zu einem Komplete 11 gehört, das du vielleicht ohnehin vorhast, zu erstehen oder zu updaten. Aber das ist genau dasselbe, wenn man immer auf noch leistungsstärkere und noch schnellere Laptops wartet. Du musst überlegen, ob es dir wichtig ist, sofort in die neue Version einzusteigen und du die 99€ über hast.

Teil 1: REAKTOR Blocks
Die REAKTOR Blocks unterschätze nicht! Ich mag sie persönlich nicht einsetzen, da sie mich von meinem eigentlichen Projekt nur ablenken. Viele Blocks, insbesondere die von Michael Hetrick (ich glaube alleine er hat schon über 100 Blocks hoch geladen) sind äußerst hochwertig und direkt einsetzbar.
Es lassen sich tatsächlich in einem kleinen Wochenendprojekt sehr schnell hochwertige monophone Patches erstellen. Die Auswahl der Blocks ist immens, schwierig wird es bei der Auswahl, denn fast jeder wagt sich daran und ist zum Teil auch stümperhaft.
Benutzte Oszillatoren und Filter sind in der von NI vorgegebenen Auswahl und wohl auch einiger Profi-Hobby-Entwickler von höchster Qualität.
Die hohe Qualität hat ihren Preis, da sie zum Teil CPU-Monster sind. Monophone Patches können schon über 30% locker erwarten. Ein Nachteil ist, dass ein Patch immer über die Ensemble-Struktur erstellt wird. Das heißt: jeder Patch ist ein Ensemble. Daher arbeite ich lieber mit meinem modular.
Die Blocks selbst sind genormte Instrumente (daher monophon), die aber durch Normen (Anzahl der Modulationseingänge), Gestaltung der Oberfläche sehr Benutzer freundlich erstellt und eingesetzt werden können.
Hier mal ein typisches Ensemble:

1.png

und die zugehörige Struktur:

2.png

[Eventmanager]

Gut erkannt,warten auf Komplet 11 ist meine Hauptüberlegung, sonst zahl ich ja zweimal.
Und da ich eh schon 6 Monate nanchhänge, die 2,3 Monate bis zu den "Wehen" kann ich mich noch gedulden;-)
Zumal es sich momentan nicht wirklich lohnt (was sich aber hoffentlich mit 6.1-6.9 noch ändern wird;-) ; abgesehn was ich NI alles ankreide, aber in punkto Update-Politik (Verbesserungen/Geschenke innerhalb einer Hauptnummer) lassen sie sich echt nicht lumpen!

Ganz simple Frage: sind mittlerweile die Speicherorte die man ja in Behaviors definieren kann, mittlerweile auch direkt "verlinkt". Hatte es eben mal wieder mal mit den Eventtable (du erinnerst dich).
Ich hab nen dezidierten Speicherort dafür konfiguriert, trotzdem haut reaktor mir (egal, bei was ich speichern will) immer den zuletzt (egal für was "öffnen-dialog" vor die Nase, sogar einen komplett ausserhalb-liegenden grafik-ordner, weil ich als letztes als ein multi-picture betankt habe???).
Was soll da also diese Mogelpackung mit Speicherort für diverse extensions??? Ist wenigstens das mittlerweile gefixt?

############
Vielleicht unterschätze ich, die Blocks. Ich denke da ist nettes Zeux dabei. Andrerseits - ich hab auch niemals eines von diesen "Buliding-blocks-macros" genutzt, selbst da ist mir idR schon viel zu viel unnüzter Code drin, und von dem was ich brauche muss ich eh noch alles adaptieren. Und sofern ich mich erinnere waren die auch noch alle "polyfon". Da ist Neu-Bau idR schneller. Ich wünsch mir nur einfach ne Option "lade neue Module in "mono", lade neuen Selektor mit 2 ports, gleich mit 2 konstanten bestückt im linear-modus... lade modul x mit allen zugehörigen "Controlls" (sauber gepanelt), sowas halt... also diverse abrufbare Voreinstellungen für Prim-Module (das teil heisst dann Selektor fac, selektor 2, selektor 16... oder resynth fac, reysnth controlls... ferner hätte ich gerne das man simple einen kosntante mit ihren 20 verdrahtungen durch eine konstante + ein add-modul ersetzen kann, oder einfach durch einen in-port, da gleiche gilt für knobs... und viceversa) einfach rechtsklick "Modul ersetzen mit...") und schwupps werden alle Nach-Verdrahtungen nicht von dem Knob sondern von dem In-port bedient...)
Ohne zu zögern hätte ich dafür auch gerne 299€, mglw. auch zweimal hingeblättert.


EDIT, anch deinem Bild-upload:
Mit obigen "ersetzen mit..." könnte man sogar BLOCKS benutzen und adaptieren, sofern man muss oder will.
BTW: boah, ey, wie die Teile schon ausssehen??? Das ist der pure Rummel "Jawoll Herschaften, das muss man gesehen haben, das muss man erlebet haben, das bringt den Puls in Wallung, da bleibt kein Auge trocken...."

Sumnmasum denke ich das Blocks für ernsthaftere Entwickler ein Schritt in die falsche Richtung ist, gerade du mit deinen eigenen, intern filigran abgestimmten "Blocks", dürftest da ebenfalls deine Bedenken haben. Die R&-Entwickler werden sich mit hundertfach Fragen nach Block-Optimierung konfrontiert sehen, und diesen nachgeben, anstatt sich um die Weiterentwicklung des eigentlichen Reaktor-Codes zu kümmern.
Für End-Konsumer ein wichtiger Schritt nach vorn, für ambitionierte Entwickler ein Faustschlag mitten auf die Nase.

BTW: die Kabel-Führung sieht rein optisch nachvollziehbarer aus als in R5 (Frage sind "Rückwärts-Kabel" noch differenzierter zu erkennen, oder bleibts bei diesem leichtem Schwing-Knick egal ob nach vorne oder nach hinten?)

[herw]

Gut erkannt,warten auf Komplet 11 ist meine Hauptüberlegung, sonst zahl ich ja zweimal.
Und da ich eh schon 6 Monate nanchhänge, die 2,3 Monate bis zu den "Wehen" kann ich mich noch gedulden;-)

das hängt natürlich von deiner Ungeduld ab. Wenn du Komplete updatest, dann liegen deine Interessen doch nicht nur bei REAKTOR, insofern zahlst du nicht unbedingt doppelt.
Wenn dir ein Update von Reaktor in Zukunft wichtig ist, dann musst du beim nächsten Majorupdate in zwölf Jahren daran denken, dass REAKTOR und KOMPLETE in der Regel mit zeitlichem Abstand liegen.

Zumal es sich momentan nicht wirklich lohnt [...]

Das stimmt nicht, wenn du selbst in core entwickeln möchtest und wenn du die aktuellen neuen User ensemble laden möchtest.

[...]Vielleicht unterschätze ich, die Blocks. Ich denke da ist nettes Zeux dabei. Andrerseits - ich hab auch niemals eines von diesen "Buliding-blocks-macros" genutzt, selbst da ist mir idR schon viel zu viel unnüzter Code drin, und von dem was ich brauche muss ich eh noch alles adaptieren. [...]Und sofern ich mich erinnere waren die auch noch alle "polyfon". Da ist Neu-Bau idR schneller.

Oh das stimmt gerade nicht. Die Idee der Blocks ist zweierlei: erstens sollen gerade Neueinsteiger ermutigt werden; das sind offenbar häufig Maschine User, die mit Komplete nun auch in REAKTOR herumschnuppern. Es ist wirklich sehr leicht, auch als Neueinsteiger ein attraktives Ensemble zu erstellen. Da reicht ein Nachmittag. Durch die Normierungen ist man sicher, dass man alles mit allem verbinden kann. Wenn man das englisch sprachige Forum eine Woche beobachtet, dann wirst du erkennnen, dass dort viele Neueinsteiger sind. Andererseits sind die Blocks auch interessant für ausgefuchste Entwickler und nur solchen bleibt das Erstellen neuer interessanter Blocks eine schöne Herausforderung. Das Umfeld, wie Panelelemente, Modulationsmöglichkeiten und das Interface, sind im Verbund völlig vorgegeben. D.h. man kann sicher sein, dass die Blocks mit anderen gut zusammenarbeiten, wenn man sich an einige Vorgaben hält.

Ich wünsch mir nur einfach ne Option "lade neue Module in "mono", lade neuen Selektor 2 ports, gleich mit 2 konstanten bestückt im linear-modus... lade modul x mit allen zugehörigen "Controlls" (sauber gepanelt), sowas halt... also diverse abrufbare Voreinstellungen für Prim-Module (das teil heisst dann Selektor fac, selektor 2, selektor 16... oder resynth fac, reysnth controlls... ferner hätte ich gerne das man simple einen kosntante mit ihren 20 verdrahtungen durch eine konstante + ein add-modul ersetzen kann, oder einfach durch einen in-port, da gleiche gilt für knobs... und viceversa) einfach rechtsklick "Modul ersetzen mit...") und schwupps werden alle Nach-Verdrahtungen nicht von dem Knob sondern von dem In-port bedient...)

Das habe ich nicht ganz kapiert, als Essenz entnehme ich, dass es dir um vereinfachte Verdrahtungen geht. In primary hilft da partials framework, das in einfacher Form auch in den Blocks benutzt wird (siehe meine Reaktor Riddles Kapitel 6 und 7), in core die neuen Bundles und distributions. Du musst akzeptieren, dass die Hauptprogrammieroberfläche core sein wird (ist). Viele verlieren mittlerweile die Scheu davor. Aber dazu komme ich in den nächsten posts. Ich will dich nicht überreden, R6 vorzeitig zu kaufen, ergreife aber die Gelegenheit, die Vorzüge des Majorupdates herauszustellen, nicht als Reklame für NI (obwohl meine Zuneigung zu REAKTOR offensichtlich ist). Ich engagiere mich für REAKTOR so sehr, weil ich nach so vielen Jahren immer noch von dem Konzept überzeugt bin und durch meine Reklame erreichen möchte, dass REAKTOR bei vielen Usern Interesse findet und so nicht stirbt.
Natürlich wünsche ich mir seit Jahren Features, die immer wieder auf die Wartebank geschoben werden. Auch die NI-Entwicklergruppe stöhnt zum Teil darüber, andererseits muss NI natürlich daran denken, wie viel Man-Power einsetzbar ist.

Ohne zu zögern hätte ich dafür auch gerne 299€, mglw. auch zweimal hingeblättert.

naja, das finde ich übertrieben; NI muss schon liefern.

[...]für ambitionierte Entwickler ein Faustschlag mitten auf die Nase.

definitiv nein; gerade in core hat sich enorm viel getan. Dazu später viel mehr

BTW: die Kabel-Führung sieht rein optisch nachvollziehbarer aus als in R5 (Frage sind "Rückwärts-Kabel" noch differenzierter zu erkennen, oder bleibts bei diesem leichtem Schwing-Knick egal ob nach vorne oder nach hinten?)

nö das ist viel übersichtlicher geworden (in core). Man würde sich das in primary auch wünschen:

3.png

[Eventmanager]

Rückkabel sieht wirklich gut aus. Das hilft sicherlich um seine Strukturen später zu enträtseln. Aber die Port-Benennung bleibt bei 3 sichtbaren Lettern, oder?

Was den Rest betrifft haben wir wahrscheinlich grundlegend verschiedene Wünsche und Erwartungen.
Und wenn ich vom bisherigen NI-Komplete-Zyklus den nächsten Termin extrapoliere, nun, solange wird das nicht mehr dauern, dann habe ich auch die schönen Rückkabel;-) und wer weiß, vielleicht gibts ja dann schon 6.1 und ich werde angenehm überrascht.

[herw]

Teil 2: Editieren

Rückkabel sieht wirklich gut aus. Das hilft sicherlich um seine Strukturen später zu enträtseln. Aber die Port-Benennung bleibt bei 3 sichtbaren Lettern, oder?

Oh da hat sich einiges getan. Abgesehen davon, dass man die Ports durch Doppelklick jederzeit direkt editieren kann, kann die Anzeige der Pirmary-Makros flexibel angezeigt werden (lange Portnamen und ein großes Icon (geht auch noch größer). Dasselbe Feature gibt es in core auch. Lediglich corecell in primary haben diese Möglichkeit eigentümlicherweise noch nicht.

4.png

Was den Rest betrifft haben wir wahrscheinlich grundlegend verschiedene Wünsche und Erwartungen.

naja die Ansprüche steigen und dadurch werden die prinzipiellen Grenzen von primary immer offenkundiger.

Und wenn ich vom bisherigen NI-Komplete-Zyklus den nächsten Termin extrapoliere, nun, solange wird das nicht mehr dauern, dann habe ich auch die schönen Rückkabel;-) und wer weiß, vielleicht gibts ja dann schon 6.1 und ich werde angenehm überrascht.

Ich denke, dass NI mit einem zukünftigen Komplete auch neue REAKTOR ensembles liefern muss (wird?), um die Stärken aufzuzeigen.

[herw]

Die Kabelverbindungen sind jetzt „geschmeidiger” dargestellt:

5.png

6.png

Das gilt sowohl für primary als auch core.
Geichzeitig erkennst du in core so genannte bundles. Mit ihnen kann man viele einzelne Kabel und auch wiederum bundles zu einem Strang vereinen ...

7.png

8.png

... und wieder einfach aufdröseln.

9.png

[herw]

Über so genannte bundle distributions (oder auch nur für einzelne Signalstränge) kann man drahtlos in tiefere Core-Ebenen zu pickups Verbindung aubauen.

10.png

In einer Programmiersprache würde man dazu vereinfacht globale Variablen sagen.

11.png

Nur dass sie in REAKTOR sehr komplex sein können.
Es gibt auch den umgekehrten Weg von tiefen Ebenen in höhere zurück.
Die Bundles werden in der Core-Library häufig benutzt, um Standarts zu schaffen: Beispiele sind Oszillatoren, Filter und Hüllkurven:

12.png

13.png

Das erste Bild zeigt eines der vielen Filter. Darüber später mehr.
Das zweite zeigt einen AHDSR-Generator. Du erkennst, dass alle Phasen mit denselben Makros erstellt werden. Nur durch die Parmeter wird deren Wirkungsweise beeinflusst. Es steht nichts im Wege, ausgedehnte Hüllkurvenverläufe neu zu erstellen, übrigens mit variablem Kurvenverlauf (Krümmung).

[herw]

Teil 3: primary library

Da ich die primary library nur sehr sparsam verwende, sind die folgenden Überblicke vielleicht unvollständig oder in der Beschreibung etwas dünn.
Wenn ich die angebotene Library durchschaue, so gibt es im Wesentlichen an Neuerungen wohl Makros, die dem Anwender Entwicklungsarbeit abnehmen.
Natürlich sind alle R5-Module vorhanden (Standardmodule), dort hat sich aber nichts Neues getan.
Die Library dagegen ist schon beeindruckend und NI hat sich sehr bemüht, aufzuzeigen, wie man anspruchvolle Panels (primary) mit Signalverarbeitungen (in core) verknüpft.
Sampler-Makros:
Sie bieten alles, was man für eine schnelle Anwendung vor allem auf dem Panel braucht.

14.png

Filter-Makros
In der Filtersektion werden „nur” vier Filter-Makros angeboten. Sie zeigen exemplarisch, wie man corecells zum Erstellen verschiedenster Filtertypen verwendet.

15.png

Im Innern sieht man, wie sehr sie auf Corecells basieren. Primary ist (nur) das Beiwerk auf dem Panel:

16.png

Beeindruckend ist dagegen, wie viele fertige Module core bietet:

17.png

Effekte
Hier mal exemplarisch ein Phaser

18.png

[Eventmanager]

Aja, ok, also n bissl was hat sich schon getan. Danke.

Lesbare ports und vor allem die bundles dürften die structure schon etwas aufräumen. Aber bundles gibts nur innerhalb core, hab ich dich da richtig verstanden?
Wie läuft das, bspw. 15 ports auswählen dann rechtscklick "erstelle bundle" oder so?

Und so wies aussieht, kann man dank der library wohl auch ohne explizite core-kenntnisse über weite strecken innerhalb der obersten core-ebene bleiben und sich Bedarf auch mal ne Ebene tiefer in den Fuchsbau wagen.

Diese "Makros" sind doch vergleichbar mit den built-in-blocks aus früheren Versionen, oder? Unter Module finde ich nach wie vor den pro52 und differentiator und wie die alle heissen? Vor allem zeigst du hier wohl nur die oberste Makro-ebene, irgendwo drin müssen ja noch mehr ports sein, ich geh mal davon aus, das die Panel-Elemente nicht ins leere laufen;-)
Zeig doch bitte mal die Sampler von "innen", also die ebene wo die panel-elemente angedockt werden.

Naja, etwas neugierig hast du mich schon gemacht;-)

[herw]

Aja, ok, also n bissl was hat sich schon getan. Danke.

Lesbare ports und vor allem die bundles dürften die structure schon etwas aufräumen. Aber bundles gibts nur innerhalb core, hab ich dich da richtig verstanden?

ja, nur in Core.

Wie läuft das, bspw. 15 ports auswählen dann rechtscklick "erstelle bundle" oder so?

Das geschieht mit einem Pack-Modul: Man legt beliebig viele Eingänge fest. Dies können einfache event-Signale, Audio-Signale oder auch wieder ganze Bundles sein; der Phantasie steht nichts im Wege. Ich benutze zum Beispiel für meinen Sequencer genestete Bundles; d.h. ich fasse zum Beispiel alle 12 Tuneregler zusammen, alle Regler und Buttons für die Kontrolle des Sequenzers etc. Das sind insgesamt 108 Signalwege. Ich unterteile, wie oben beschrieben, diese 108 Signalwege in Untergruppen.
Ich kann sie wieder entpacken oder wenn ich möchte auch durch die distributions direkt in core ohne Kabelverbindung aufrufen.
In Primary gibt es Vergleichbares zum Beispiel mit den Send-Receive-Verbindungen, die aber wesentlich unflexibler und anfälliger sind (zum Beispiel beim Kopieren und wider einfügen.
Man kann diese Bundles auch nach bestimmten Kriterien (Namensgebung) wieder splitten und auch neu zusammenfügen.
Packen:

19.png

,

20.png

Entpacken:

21.png

Hier habe ich zum Beispiel jeden Tune-Wert mit einem Index versehen, die gleichzeitig gesendet werden und kann so beim Entpacken gleich in ein Core-Array einlesen lassen.

Und so wies aussieht, kann man dank der library wohl auch ohne explizite core-kenntnisse über weite strecken innerhalb der obersten core-ebene bleiben und sich Bedarf auch mal ne Ebene tiefer in den Fuchsbau wagen.

ja; core ist aber auch nicht wirklich schwer, wenn man sich einmal traut. Ich helfe im englischsprachigen Forum mit meinem Thread REAKTOR RIDDLES.

Diese "Makros" sind doch vergleichbar mit den built-in-blocks aus früheren Versionen, oder?

ja, nur wesentlich ausgereifter.

Unter Module finde ich nach wie vor den pro52 und differentiator und wie die alle heissen?

ja, die alte R5 Library ist komplett weiterhin nutzbar und wird beim Updaten nicht überschrieben.

[herw]

Vor allem zeigst du hier wohl nur die oberste Makro-ebene, irgendwo drin müssen ja noch mehr ports sein, ich geh mal davon aus, das die Panel-Elemente nicht ins leere laufen;-)
Zeig doch bitte mal die Sampler von "innen", also die ebene wo die panel-elemente angedockt werden.

Da gibt es viel zu zeigen ich gehe mal einige Ebenen tief:

22.png

23.png

Hier zunächst mal links in den Panelbereich; dort werden mit Hilfe eines Mausfeldes die Samples per Drag-and-Drop geladen. Schlag mich nicht, ich habe es noch nicht ausprobiert.

24.png

und nun nach rechts in das graincloud core:

25.png

und zwei Ebenen tiefer:

26.png

und noch tiefer der eigentliche Sampler.

27.png

Links kannst du übrigens einen Pickup erkennen: ↳PanelCtls. Er wurde im vorletzten Bild definiert (gleicher Name).

Naja, etwas neugierig hast du mich schon gemacht;-)

Nunja, das sind ja nur formale Änderungen. Die Hauptsache kommt noch in den nächsten posts:

achja und so sieht es draußen aus

28.png

[Eventmanager]

man, jetzt hast du mich aber doch ein bissl angefixt, sch+++ pusher;-)

Bündel klingt richtig gut und ist wohl eher mit mux/demux vergleichbar als mit diesem halbgaren send/recieve-Konzept, wo echte strippen unterm strich doch schneller und nachvollziehbarer sind, also leichter zu detecktieren was jetzt wo mit wem, wie genau verbändelt ist.
Mal ganz abgesehen, das send/recieve oder zumindest die IC-brüder davon erheblich die Ladezeit negativ beeinflussen, man bei jedem cmd+x/c/v das Areal Abenteuerspielplatz betritt und schlussendlich mehr Arbeit hat, als wenn man vornherein auf ehrliuche Strippen gesetzt hätte. Zumindest wenn man hin und wieder updated/die alte Struktur neu-durchblicken muss....

Da scheinen mir die Bundles ne Idee ausgereifter, ich hoffe mal an es ist möglich am Zielort aus dem "demuxer" nur die ports zu extrahieren, die man dort wirklich brauchtl? Das wäre echt klasse!

''''''''''''''''''''
Sampler sieht auch interessant aus, ich verstehe nur nicht, ist das nun ein Core:modul oder hangelst du dich allmählich von dem "Makro" runter zur Prim-Ebene (auch wenn die neue view definitiv besser ist, ich kann sie momentan nicht wirklich entwirren, muss mir erstmal die grafische "syntax" draufschaffen, aber ganz unten sieht das nicht wie prim aus).

Eindeutig interessant.
Der Haupt-Schwachpunkt bei den alten Samplern, ist aber nicht die (Re)synthes, sondern das archaische Map/Editor Handling.
Das beginnt damit das die Meta-Informationen (pitch, loop-settings entweder garnicht oder nur fehlerhaft importiert werden)
Ferner ist batch-handling komplett unmöglich (ich habe 127 c1 samples, bitte alle in einen rutsch darauf "re-pitchen").
Und vor allem Trigger, vor allem Re-trigger ist immer Hüllkurven-Betonkopp-like. Egal Egal wo wir uns grad im Sample befinden, wie hoch der aktuelle Ausschlag ist, Retrigger- wir springen sofort ohne jegliche Interpolation auf Null/Samplestart-Punkt. Man muss nicht besonders weitsichtig sein um zu erkennen, das es bestenfalls per Zufall hin und wieder passende Übergänge gibt, der Großteil wird mit Knacksern quittiert.
Der ableton-sampler (simpler) ist überigens genauso behindert, das es aber auch anders geht, zeigt kontakt und bitwig. Hier sind selbst kürzeste Staccatos immer schön smooth, ohne plops und klicks. und selbst maschine retriggerd weitaus besser (jedesmal mit exact demselben sample, den gleichen noten und vergleichbaren hüllkurven getestet, die unterschiede sind selbst bei 8-tel-"Staccato" exorbitant, mein winner ist übrigens nicht kontakt, es ist der give-away-bitwig sampler, dann kontakt, dann maschine (alle drei akzeptabel), dann reaktor und schlusslicht ist simpler (beide bei "kritischen" samples völlig indiskutabel, nur mit extrem modifizierten hüllkurven halbwegs brauchbar).
Was ich sagen will, ein core-sampler, der einem möglichweise zugriff auf eben jenes handling leifert (das sich weder über loop-size (weder am modul, noch im file, noch in external editor...) noch adadhrbsdrhsr... regeln lässt... jawoll, so ein "modul" ist mehr als überfällig. Wann wurde das letzte sampler-modul released? mit R3, oder?

[Eventmanager]

Was aber schinbar nach wie vor nicht geht, ist das bequeme handling, aus der reaktor-gui auf die festplatte zu zu greifen. "Drop your sample" ist doch nur ein allererster Schritt, eigentlich will ich, sofern erstmal ein finder-ordner damit "verlinkt ist, mich mittels prev-next-skip-buttons durch den ordner wühlen, sample testen und bei gefallen als preset (inklusive dem sample) im ensemble speichern.
Um das zu tun, führt nach wie vor kein Weg um die alten (file-size-fetten) maps, oder saved mittlerweile ein preset jetzt auch die dynamisch eingebeamten samples irgendwo, resp. die reference darauf, und ruft später den sampler bei preset-wechsel wieder mit eben jenen sample auf????

[herw]

man, jetzt hast du mich aber doch ein bissl angefixt, sch+++ pusher;-)

Bündel klingt richtig gut und ist wohl eher mit mux/demux vergleichbar als mit diesem halbgaren send/recieve-Konzept, wo echte strippen unterm strich doch schneller und nachvollziehbarer sind, also leichter zu detecktieren was jetzt wo mit wem, wie genau verbändelt ist.
Mal ganz abgesehen, das send/recieve oder zumindest die IC-brüder davon erheblich die Ladezeit negativ beeinflussen, man bei jedem cmd+x/c/v das Areal Abenteuerspielplatz betritt und schlussendlich mehr Arbeit hat, als wenn man vornherein auf ehrliuche Strippen gesetzt hätte. Zumindest wenn man hin und wieder updated/die alte Struktur neu-durchblicken muss....

Da scheinen mir die Bundles ne Idee ausgereifter, ich hoffe mal an es ist möglich am Zielort aus dem "demuxer" nur die ports zu extrahieren, die man dort wirklich brauchtl? Das wäre echt klasse!

genauso funktioniert es

''''''''''''''''''''
Sampler sieht auch interessant aus, ich verstehe nur nicht, ist das nun ein Core:modul oder hangelst du dich allmählich von dem "Makro" runter zur Prim-Ebene (auch wenn die neue view definitiv besser ist, ich kann sie momentan nicht wirklich entwirren, muss mir erstmal die grafische "syntax" draufschaffen, aber ganz unten sieht das nicht wie prim aus).

wir reden hier bisher nur über die Makros der primary library. Diese Makros sind, wie du richtig erkannt hast, eine Kombination aus primary und core. Primary übernimmt hierbei fast nur noch die Informationen des Panel anzunehmen und an core Makros weiterzugeben. D.h. die Signalverarbeitung geschieht in den coreCells. Natürlich kannst du nach wie vor beim primary-Stil bleiben, die Kompatibilität bleibt. Aber die richtig feinen Sachen erledigt man (NI) jetzt in core, da dort ein viel gezielterer Zugriff auf audio und Event möglich ist.

Eindeutig interessant.
Der Haupt-Schwachpunkt bei den alten Samplern, ist aber nicht die (Re)synthes, sondern das archaische Map/Editor Handling.
Das beginnt damit das die Meta-Informationen (pitch, loop-settings entweder garnicht oder nur fehlerhaft importiert werden)
Ferner ist batch-handling komplett unmöglich (ich habe 127 c1 samples, bitte alle in einen rutsch darauf "re-pitchen").
Und vor allem Trigger, vor allem Re-trigger ist immer Hüllkurven-Betonkopp-like. Egal Egal wo wir uns grad im Sample befinden, wie hoch der aktuelle Ausschlag ist, Retrigger- wir springen sofort ohne jegliche Interpolation auf Null/Samplestart-Punkt. Man muss nicht besonders weitsichtig sein um zu erkennen, das es bestenfalls per Zufall hin und wieder passende Übergänge gibt, der Großteil wird mit Knacksern quittiert.
Der ableton-sampler (simpler) ist überigens genauso behindert, das es aber auch anders geht, zeigt kontakt und bitwig. Hier sind selbst kürzeste Staccatos immer schön smooth, ohne plops und klicks. und selbst maschine retriggerd weitaus besser (jedesmal mit exact demselben sample, den gleichen noten und vergleichbaren hüllkurven getestet, die unterschiede sind selbst bei 8-tel-"Staccato" exorbitant, mein winner ist übrigens nicht kontakt, es ist der give-away-bitwig sampler, dann kontakt, dann maschine (alle drei akzeptabel), dann reaktor und schlusslicht ist simpler (beide bei "kritischen" samples völlig indiskutabel, nur mit extrem modifizierten hüllkurven halbwegs brauchbar).
Was ich sagen will, ein core-sampler, der einem möglichweise zugriff auf eben jenes handling leifert (das sich weder über loop-size (weder am modul, noch im file, noch in external editor...) noch adadhrbsdrhsr... regeln lässt... jawoll, so ein "modul" ist mehr als überfällig. Wann wurde das letzte sampler-modul released? mit R3, oder?

zu den sampler Makros kann ich nichts weiter sagen, da dies (leider) nicht mein Gebiet ist.