R6 vs R5, ja es gibt Nachteile (auch unter der Haube)

[Eventmanager]

Bin jetzt endlich ernsthafter mit v6 unterwegs, aber auch immer noch mit einem Projekt zwangsweise mit R5... so halbe halbe aktuell! Im Direktvergleich merkt man schon deutliche Unterschiede und nicht immer zum Vorteil von R6.
Mal GUI und Nutzerfreundlichkeit/Effizienz... komplett aussen vor (beide Versionen sind in diesen Punkten bestenfalls Albanien, wenn nicht gar Afghanistan, jedenfalls weit weg von Californien oder gar Japan...) nee, auch unter der Haube, gibts Unterschiede.

POSITIV:
R6 scheint ne neue Midi-Out-Host-Kommunikation zu haben. Midi-Daten sind jetzt straight as hell, egal bei welcher Latenz! ABSOLUT SAUBER !!!! NULL Jitter, selbst bei Sample-Zoom ist es PERFEKT! Und nicht wie in R5 (bei hoher Latenz) fast im 128-tel note Bereich, also durchaus hörbar bei 120BPM... bei 32Sample Latenz zwar weniger aber tighte drummer hören auch 512er Versatz... mal ganz abgesehen von schlecht gecodeteen VSTis die sich da gerne verschlucken! Nope, in R6 sind Midi-Outs hoch präzise, ja komplett exakt auf Punkt, egal bei welcher Latenz/BPM... Allerdings mit ner Art "Negativ-Delay", wahrscheinlich um den generellen Plug-in Versatz zu kompensieren???? Jedenfalls ist alles exakt auf diesem "Versatz-Punkt".... mit KONSTANTEM Delay/Vorziehen kann man ziemlich gut leben - bei Random-Jitter siehts deutlich dramatischer aus. Also DAS hat NI vorbildlich gelöst! Hut ab und Danke!

NEGATIV / Rückschritt:

Deutlich längere Load-time bei R6. Mglw liegst auch am "smart-ram"... und anderen OS-Stunts, häufig benutzte Apps, besondere Optimierungen und auch Reaktors (background-load-file-optimation-folder) der natürlich erstmal gefüttert werden muss... Aber bei einem NACKTEM Reaktor und einer PUREN SSD ... was gibts sonst so Faktoren, die mglw. ne Rolle spielen könnten? Es fällt SIGNIFIKANT auf das ein NACKTES!!!! R6 deutlich benötigt als R5 (auf meiner Kiste ca. 2 sekunden vs 5 sekunden also mindestens Faktor 2). Auch als Plugin benötigt ein NACKTES R6 DEUTLICH länger, ein gefülltes natürlich ebenso!

Die crumb-Leiste, oder wie immer auch diese "Shortcuts"/ spezielle Jump-Ansichten... heissen... in R6 fast ein "Geduldsspiel". Es dauert zwar nur ca. Sekunde, aber man wiess nie genau, hat man das nun "getriggert" oder nicht. Scheint das Reaktor nun auch diesem grauenvollen OSX mode folgt, das nicht Maus-klick sondern erst maus-klick+loslassen wirklich triggert... Und manchmal triggert es eben nicht, oder verschluckt sich, weil klick/loslassen zu schnell???? ... oder die Geschichte ist auf andere Weise deutlich indirekter geworden????? In R5 wird jedenfalls INSTANTAN bei KLICK (nicht er,st bei loslassen) SOFORT zur Ansicht gewechselt!
Löblich in R6 der Klarname/Umbennung, das drag/drop-Verschieben... (aber hier gehts nich um GUI, verdient trotzdem Erwähnung - kein Afghanistan mehr, und schon fast Kroatien, statt Albanien... aber noch Gigameilen von Japan entfernt... warum keine shortys dafür, warum kein smart-algorithmus, nur das linke "fenster" als default-name.... warum auf der anderen Seite kein for/back, das unabhänig davon, wohin ich gejumpt bin, einfach zur letzen, vorletzen... Ansicht vor/rück wechselt... warum kein temporäres PIN... das wäre Japan, aber einstweilen bin ich über Kroatien schon recht zufrieden;-)



Am allernervigsten in Reaktor ist, das manche KORREKTE Verdrahtungen... erst nach switch, manche erst nach power/off, andere sogar erst nach restart sichtbar sind! Und ich rede hier von Primary! KA wieviele Stunden ich insgesammt vor pseudo-falschen Verdrahtungen verbracht habe, den Fehler gesucht habe... dabei war ein simples power on/off (ergo ein KOMPLETTES init) der einzige Fehler! Bei Pictures in bspw. Multi-Displays, muss dann sogar re-öffnen..., oder gar bei banalen Dingen, wenn der Mausfokus verrutscht ist (letzteres ist in R6 und den View-Levels schon deutlich besser, aber selbst hier muss man extrem tricksen. Warum nicht einfach ein "grösseres Element" als reines VIEW_Element definieren... ein versehentlicher "KLICK darauf" hat absolut keine Bewandniss, denn es ist IMMER ganz hinten, reines Deko-elemt...nur geringfügig höher als das Background-Picture...
Aber auch darum gehts nicht... es geht darum das R6 (gefühlt) mehr Power off/ons benötigt um die neue Structure zu testen. Auch in R5 kommt bei neuen Selektor, Modulo, Logic..... oft hinten nicht Eingang X raus... egal wie oft durchgesteppt, gar geswicht... erst globales power off/on... bringt hier die Gewissheit: Mein Fehler / alles korrekt, aber momentan out of order....
Das ist in R5 schon nervig, in R6 hat sich das aber noch verschärft! Warum nicht einfach ein Quick-DEBUG-Mode, wo nach JEDEM Strippenziehen/neues Modul einsetzen... ein KOMPLETTES Init (oder was auch immer verantwortlich ist) durchgeführt wird... Ein solcher manueller Mode, der natürlich. knackst, knarzt, noch deutlicher Artefact...uU 1,2 Sekunden dauert... wäre zumindest eine NOTWENDIGE Option. Ein smart-Modus, der das auschliesslich bei allen bekannten Momenten durchführt, natürlich besser? Was auf keinen Fall geht, den Strippenzieher im BLIND-MODUS, oft stundenlang im Dunkeln, bei einer EIGENTLICH, funzenden Struktur, tappen zu lassen, bis "MAGIC" durch Zufall, oder sonstwas endlich mal Komplett-Init wird....
Wahrscheinlich ist R& neues INIT-Konzept im ALLGEMEINEN besser... aber hier nervt es NOCH mehr! Sobald ich zwischen PLAY und EDIT wechsel kann ich drei "smarte" Intensitätsstufen des Re-Init" wählen... und sie jederzeit wechseln, je nachdem an welch kritische / bekannte bugs ich mich grad heranwage!

[herw]

Hallo eventmanger,
deine Post ist ziemlich lang und springt inhaltlich etwas hin und her; die Metaphern mit Afghanistan, Japan etc. verstehe ich nicht.
Es wäre gut, wenn du Bugs, Kritiken etc. im Unterforum Kernschmelze formulieren würdest. Kleine konkrete Beispiele helfen den anderen Forenmitgliedern, darauf zu antworten.
Ich verschiebe deinen Thread entsprechend in das Unterforum Kernschmelze.

[Eventmanager]

Diese SUB ist idT der bessere Ort für dergleichen.

Konkrete Beispiele:

- Es kommt vor, das ein FRISCHER Selector die values nicht transmitted, auch nicht durchswitchen durch alle steps, erst nach deactivate/activate funzt reaktor.

- Neue images (also noch nicht angemeldete, anderswo aktive) in Multi/Polydisplays werden erst nach Neustart des Ensembles sichtbar.

- Ich hab nen "source-ens (rund 5-7% cpu) " und ein effekt-ens (zwischen 7-15%). Füge ich nun das effekt-ens in die strukter des source-ens, steigt seine/die insgesamte Last deutlich höher als die summe beider. Gehe ich den anderen Weg, das source-ens in das effekt-ens einzufügen, bleibt es ungefähr bei simpler addition beider lasten???

[herw]

[...]
- Es kommt vor, das ein FRISCHER Selector die values nicht transmitted, auch nicht durchswitchen durch alle steps, erst nach deactivate/activate funzt reaktor.
[...]

primary oder core? Wenn du in core editierst, dann wird (systembedingt) nur das aktive Makro kompiliert. Daher muss man beim Arbeiten in core immer deactive/active benutzen (Falle!).

[herw]

[...]
- Ich hab nen "source-ens (rund 5-7% cpu) " und ein effekt-ens (zwischen 7-15%). Füge ich nun das effekt-ens in die strukter des source-ens, steigt seine/die insgesamte Last deutlich höher als die summe beider. Gehe ich den anderen Weg, das source-ens in das effekt-ens einzufügen, bleibt es ungefähr bei simpler addition beider lasten???

Achte auf die Stimmenzahl?

[Eventmanager]

Ich würd mir nicht anmassen, bei selbstgebaselten Core modulen den fehler in Reaktor allgemein, statt in meiner structur zu suchen. Nope ich meine nen üblichen FRISCH eingesetzen Prim-Selector. Wie gesagt, betrifft es auch nicht den Selector im Allgemein, und das Prob tritt auch nicht ständig auf, mir ist eben nur eben 2 mal bei FRISCH eingefügten Selector aufgefallen. Nach power off/on war es auch behoben. Also schwer zu reproduzieren, da nach neustart, etc. ja komplett obsolet. Da brächte man wohl ne log-datei.
BTW: bei core weiss ich nur, das die demuxer, zumindest meine "alten", keine ahnung ob noch aktuell? ebenfalls gerne beim einsetzen bocken und erst nach power off ihren Dienst antreten. Wenn man das weiss, dann lässt sich ja auch damit leben - bei mysteriösem Fehlverhalten als erstes einfach schnell ab/anschalten um diese potenzielle fehlerquelle auszuschliessen, bzw. fürs instant-debug, statt ergebnislos woanders erstmal zu rätseln.

Beides "mono" instrumente, zumindest sind alle audio-module mono. der event-kram hüben wie drüben 32stimmig, wenn nötig, ansonsten auch dieser, soweit es geht, mono.

[Thala]

[...]
- Ich hab nen "source-ens (rund 5-7% cpu) " und ein effekt-ens (zwischen 7-15%). Füge ich nun das effekt-ens in die strukter des source-ens, steigt seine/die insgesamte Last deutlich höher als die summe beider. Gehe ich den anderen Weg, das source-ens in das effekt-ens einzufügen, bleibt es ungefähr bei simpler addition beider lasten???

Achte auf die Stimmenzahl?

https://www.native-instruments.com/foru ... ss.348377/

[Thala]

[...]
- Es kommt vor, das ein FRISCHER Selector die values nicht transmitted, auch nicht durchswitchen durch alle steps, erst nach deactivate/activate funzt reaktor.
[...]

primary oder core? Wenn du in core editierst, dann wird (systembedingt) nur das aktive Makro kompiliert. Daher muss man beim Arbeiten in core immer deactive/active benutzen (Falle!).

der selector verhaelt sich wie ein core router.
latchen und triggern muss man selber. (primary value modul zb)

[Eventmanager]

Dank dir Thala, interessanter, aufschlussreicher link. Jo, die beiden INS haben exorbitante Unterschiede im core/prim Verhältnis. (A) enthält bestenfalls 5% core. (B) enthält ne menge macros, mit extrem viel core.

"Route" ich nun A in bereits existierendes B ist der gemeinsame CPU_Bedarf ungefähr simple Addition beider Teile. Ganz anders wenn B (das viel core INS) später in A gestöpselt wird. Keine Ahnung ob B bei der Variante als "Add-on"nochnmal komplett neu (sehr zum Nachteil "zusatz-kompiliert" wird...) und im oppositionellen Falle einfach den alten, gut kompilierten Code behält, aber das wäre ne erklärung für dieses mysterium. Für die Praxis weiss ich jetzt jedenfalls in welcher Reihenfolge ich dergleichen zusammen zu stöpseln habe um dergleichen zu umgehen. Um den Rest soll sich das "zwei-mann-team" kümmern, kein bock mehr, deren job zu erledigen, sich den mund fusselig zu reden... Wenn MAX/MSP endlich die Möglichkeit anbieten würde, VSTi zu kompilieren, hätte ich Reaktor schon längst gekündigt, egal wie schwer und arbeitsintensiv der Übergang wäre, aber von NI erwarte ich schon lange nichts mehr, da hab ich bereits innerlich gelkümmert und nachlassverwalte gewissermassen nur noch, oder lass mich vielleicht, vielleicht angenehm überraschen am Sanktnimmerleins-Tag.

####
Was den Prim-Selektor angeht, das war zumindest in v5 anders. Ich kann mich in über 10 Jahren an keine einzige Situation wo ich diesen "anmelden" musste, erinnern. In R6 ists mir innerhalb kürzester zweimal (aber nicht ständig) aufgefallen. Es lässt sich auch so einfach nicht reproduzieren, es ist eindeutig kein WIRD, es ist ein KANN passieren, das macht es so dubios!
Ausser das nervige schalt "mono", wähle "none" als curve, bestücke 2 ports mit Konstanten... (mein 95% "default", das sich leider bis heute nicht speichern lässt) also abgesehen von diesen abermillionen extra-klicks im laufe der Jahre... habe ich NIE erlebt, das ein frisches Prim-Selector erstmal die Arbeit verweigert!
#####

Wie auch immer: R5 war zu R4 war ein richtig großer Wurf! ich hatte damals seit der Ankündigung, die Tage wie Leinkind zu Weihnachten gezählt ._) R6 zu R5 ist für mich leider nur nur ein Gimmick-Upgrade. Wobei es ein paar Kleinigkeiten gibt, die ich wahrlich nicht missen möchte, die aber schon in R5 längst überfallig waren:

Mein Top 5:

-Neues externes Host-communication / Midi-Protokoll. Also hier muss ich schon sagen: 100% korrekt NI, ohne wenn und aber! Es gibt partout keinen Jitter mehr. Extrem sauber alles! Hervorragend!

- Endlich panel-elemente zu "leveln". Das eröffnet schon versteckte, neue (UI) Möglichkeiten, zumindest das "Bugfix" wenn versehntlich ein Pixel daneben geklickt wurde und plötzlich keine Eingabe mehr möglich war, wird damit eliminiert... Leider bleibt es beim geiteskränken stacked macro konzept - warum kein neues global-IDX und ein logic-modul davor, sofern eingesetzt: diese Macro ist nur sichtbar WENN irgendwo global diese oder jene Bedingung erfüllt ist, ansonsten nicht????? Stattdessen bleibst bei diesem Irrsinn an doppel-verdrahtung in extra-macro und vor allem diesem unsäglichen, hochgradig nervenaufreibenden rumgespringe bei simpelsten verschieben... Für Abwärtskompatibilität verstehe ich ja das Beibehalten, aber nach 15 Jahren leben mit diesem Irrsinn... hier hätte ich wirklich was echt neues erwartet. Was ist so schwer an meinem obigen Vorschlag? 2 neue Module: Ein globales IDX als Sender, individuelle IDX als Empfänger, den Rest erledigen übliche matrix/logic module! Jedes Macro ohne IDX ist immer sichtbar. Was ist so schwer daran?).

- Klarnamen in der beat-crumb leiste erhöhen die Übersicht schon (warum aber nach wie vor kein simpler vor/zurück der dynamisch zwischen beiden letzen sprung-punkten wechselt, auch wenn eben nicht als dezidiertes sprungziel definiert.

-Panel-Elemente endlich mit anderen Fonts/Farben zu versehen isst schon nett und über-überfällig. Das DEINE Systemfonts nicht auf jeder Maschine laufen... versteh ich schon, die Einschränkung. Aber warum ausgerechnet diese 5 fonts? Warum nicht User ihre 3 FREE Lieblingsfonts posten lassen, dann erstmal 1000 oder so auswählen lassen, dann nochmal ne Stichwahl nur damit und schlussendlich haben wir 100 Fonts, die ÜBERALL-Entwicklungen gewährleisten. Die paar MB mehr und die paar Dankeschön-Euro für die Font-Designer, die sich einfach gehören würden... machen den Kohl nun wahrlich fett, wenn man bedenkt, wie ressorcen-freudig NI sonst mit allem umgeht!

- Maus-Area hat Zuwachs bekommen. Bin noch am exploren. Sehe aber prinzipiell Potenzial. Trotzdem stellt sich die Frage, warum wurde mit R6 nicht auch die Möglichkeit SONDERTASTEN als teil dieses Modul zu nutzen, endlich implementiert. Ob oder wie das im Host funzen könnte, ersp. dort Thouowabohu versurachen KÖNNTE, steht doch einstweilen auf nen Blatt. Reaktor wird doch wohl in der Lage zu unterscheiden, ob Ensmeble XY NATIV oder im Host aufgerufen wurde. Einstweilen könnte man doch Sondertasten erstmal für den Host sperren, aber was spricht dagegen sie Nativ zu nutzen? das beispielsweise der Buchstabe "Q" auch Midi-note #60 bedeuten könnte? Nun, dann lässt man auch dergleichen per default aus, ebnso das cmd+number irgendne Spezialsicht in Reaktor aufrufen kann. Wenn in den Options "Nutzbar mit Sondertasten" angecheckt wurde, dann sind das wahrscheinlich Nerds die das nutzen, die also sehr wohl um die Zusammenhänge und mögliche Probleme wissen, wenn sie einen enstsprechende Warnung zu lesen bekommen. Warum also nicht dergleichen für "EINGEWEIHTE" Nutzer verfügbar machen? Man stelle sich die Möglichkeiten, die 5 hoch 5 Möglichkeiten bei konsequenter Nutzung von allen möglichen combis die cmd/alt/ctrl/shift/rechts auf EINER mausarea imstande wären! Ob das end-user-freundlich wäre steht auf nen andern Blatt, aber der "end-user" bleibt davon unbehellig... es wäre aber auf jeden Fall hochgradig "Nerd"-freundlich!

Fazit: Von millionen Arbeitserleichterungen, die ich mir erhofft hatte, wurden exakt NULL in Ziffern 0, umgesetzt! Trotzdem: Die 99€ fürs verspätete Summer-Special-Update hab ich nicht wirklich bereut, es gibt paar Kleinigkeiten, die sich echt gelohnt haben. Aber hätte es einen ähnliches Upgrade wie von R4>R5 auch mit R5>R6 ich hätte SOFORT, aber SOFORT, ohne auch nur nen Planck zu zögern, das Zehnfache bezahlt!

####

Gibts sonst noch was, wo ich sage, jo das Upgrade hat sich gelohnt?
Auf jeden Fall nen neuen ACEW, andere neue Module, aber die wären wahrscheinlich auch ohne r& möglich gewesen? und selbst, wenn nicht, gilt hier mein Dank den Entwicklern der Module... nicht NI.

####

Unterm Strich verbleibt halt nur marginaler Kinkerlitz, ein Nachkomma-Update, der besser ist. Aber vielleicht bin ich acuh zu alt und verbhrt und hab die Großartigkeit noch nicht erkannt