R6 ein radikaler Schnitt

Forum für allgemeine Reaktorfragen

Moderator: herw

REAKTOR 6 eine Revolution?

REAKTOR 6 soll einen radikalen Schnitt machen
6
32%
REAKTOR 6 soll REAKTOR 5 abwärtskompatibel weiterentwickeln
8
42%
REAKTOR 6 soll Core wieder beseitigen, dafür ausgeklügelte Panelelemente bereitstellen
1
5%
REAKTOR 6 ist mir egal, mir genügt REAKTOR 5
4
21%
 
Insgesamt abgegebene Stimmen: 19

Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

R6 ein radikaler Schnitt

Beitrag von herw »

helmsklamm hat in einem anderen Thread einen radikalen Schnitt zu R5 gefordert.

Soll R6 ein Neuanfang sein, der alles alte über Bord wirft und damit viele Kompromisse (Bugs) beseitigt? oder :
soll REAKTOR vorsichtig abwärtskompatibel weiterentwickelt werden, oder :
Core ist mir nur lästig, also weg damit oder :
mich interessiert nicht REAKTOR 6, ich bleibe bei REAKTOR 5.

Eure Meinung!!
Zuletzt geändert von herw am 11. November 2007, 10:24, insgesamt 2-mal geändert.
helmsklamm
synth gott
Beiträge: 1011
Registriert: 10. Mai 2006, 16:21
Wohnort: 030

Beitrag von helmsklamm »

da es bislang erst 2 stimmen gibt, weiß ich jetzt wie du drüber denkst;)

es wär schön, wenn hier nicht nur gepollt würde, sondern auch kurz dazu argumentiert würde.

mein standpunkt:
ich bin für reaktor SX (oder wie auch immer) anstelle reaktor 6, weil die nachteile einer radikaleren neuentwicklung, sehr sehr schnell angesichts der vorteile vergessen wären.

was sind die nachteile?
ich sehe nur 2: einmal ne erhöhte einarbeitungs/umgewöhnungszeit und die tatsache das prä-"sx" ensembles wahrscheinlich nicht in dieser version laufen. und noch nen viertel-punkt: vielleicht wäre dieses "update" n paar euro teurer als sonst - würde ich aber leibend gern zahlen.

was sind die vorteile (resp. "könnten es sein")?
nun, wenn man technisch überholte altlasten ohne rücksicht auf abwärtskompatibilität über bord werfen könnte, dürfte die stabilität und die performance nen deutlichen schub nach vorne bekommen.

gewisse module oder bedienkonzepte sind einfach alles andere als intuitiv, sondern unötig umwegig und teilweise voller unnötiger stolperfallen (der ganze ensemble/instrumenten quatsch könnte viel eleganter bewerkstelligt werden, und module wie bspw. IC - also ehrlich: es kann doch nicht sein, das man bei dergleichen "simplen" teilen erstmal nen monat rumexperimentieren muss).

ergonomie/bedienkomfort und ergebnissgeschwindigkeit dürften ebenfalls von ner kompletten neuorientierung deutlich profitieren. ja, das setzt ne einarbeitung vorraus, aber die später gewonne zeit dürfte das entschieden wett machen.

core sollte auf jeden beibehalten/entwickelt werden und wenn es dereinst performance -und interface-technisch mit prim auf augenhöhe steht, dieses von mir aus komplett ablösen. bis es soweit ist, könnte aber prim erstmalne gründliche frischzellenkur injiziert bekommen (das knob/send verhalten bspw. zeigt ja, das irgendwo ganz tief n paar elementare unstimmigkeiten rumspuken.)
bitte vor jeder frage erstmal überprüfen, ob das kapitel "mein erster synth" S. 76 im hnadbuch, schon gelesen wurde.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Beitrag von herw »

helmsklamm hat geschrieben:da es bislang erst 2 stimmen gibt, weiß ich jetzt wie du drüber denkst;)
...
hihi FALSCH - ich habe deswegen extra noch NICHT abgestimmt!

PS: was wäre denn meine Meinung gewesen?
Zuletzt geändert von herw am 8. Februar 2007, 16:47, insgesamt 1-mal geändert.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Beitrag von herw »

Ich habe - wie schon oben erwähnt - noch nicht abgestimmt, sondern möchte mir hier auch erst einmal eine Meinung bilden und diskutieren.

@helmsklamm: das soll ein Neuanfang sein? Was ist denn daran radikal? Das IC-Send korrekt (besser einsichtiger) zu gestalten und einige Panelelemente anzupassen und das Core aufzubessern halte ich für ein Schmankerl, das man einem Minorupdate schenken sollte.
Die Nachteile, die sich hier ergeben (Abwärtskompatibilität) lassen sich in der Regel schnell ausmerzen, da z.B: IC-Sends sowieso von fast niemandem in kritischen Bereichen benutzt werden, wenn überhaupt. Die Bedienkonzepte müssten wirklich einheitlicher sein - auch die Midifizierbarkeit. Aber das sind alles keine umwälzenden Neuerungen. Das würde ich noch nicht R6 nennen.
Nein, wenn schon Revolution, dann aber richtig:
  • Primary-Level nur noch für Panelelemente. Alle Panelelemente müssen midifizierbar sein und vor allem auch Ausweitung auf das OSC-Konzept. Hilfsmittel zur Gestaltung (Texte, Zahlen, Regler, Fader etc.)- ein Kabelsystem auf dem Panel - Messmodule für das debugging
  • Das Core-Konzept muss stark erweitert werden mit event-Ausgängen in Audio-Core-Zellen - ein Bussystem für Audio- und Event-Signale - eine vernünftige Speicherverwaltung (Abspeichern, Editieren und Laden von Audio- und Eventtabellen - eventuell auch auf primary-level)
    Die Core-Bibliothek ist noch völlig unvollständig. Ich denke, dass NI die Lern- und Gestaltungsfähigkeit seiner User überschätzt hat.
    Es sind nur wenige bereit und in der Lage auch nur einfache neue Module zu entwickeln (z.B. Standardfilter, Standardoszillatoren) - eine Schnittstelle für entfernte Verbindungen in Core ähnlich den send-receive des primary levels.
  • Einführung einer Skriptsprache, um zum Beispiel intelligente Abläufe wie in Kontakt aufrufen zu können
helmsklamm
synth gott
Beiträge: 1011
Registriert: 10. Mai 2006, 16:21
Wohnort: 030

Beitrag von helmsklamm »

schon richtig herw, was du gelesen hast klingt nich sonderlich umwälzend - der text sollte ja als generelle frage/standpunkt dienen und nicht on detail bestimmte punkte klassifizieren.
ich hab auch keine ahnung was in der engine alles als altlast eingestuft werden kann, denke aber das da bestimmt einiges zusammenkommt. (die tatsache das mausreso und num step überhaupt bei der werteausgabe wechselwirken halt ich schonmal für technisch ässuerst fraglich - schliesslich sollte die mausreso ausschleisslich dem gewünschten bewegungshub (= mm die ich zurücklegen muss um komplett von min nach max zu kommen) entsprechen und dürfte null auswirkungen auf die werteausgabe (hakler, rundungsfehler oder wie du das auch immer nennen willst) haben. oder die tatsache das n send und n knob mit ner "falschen" range einen absturz provozieren können - also mE is da ganz tief irgendwo n kardinalsfehler, und das is sicher nicht der einzige - sie alle können aber nich behoben werden, weils dann vorbei mit der abwärstkompatibilität ist.
ich hab aber heute nich bis nackig zeit, mach jetzt erstmal hier schluss.
bitte vor jeder frage erstmal überprüfen, ob das kapitel "mein erster synth" S. 76 im hnadbuch, schon gelesen wurde.
Benutzeravatar
toxonic
synth professor
Beiträge: 322
Registriert: 2. Januar 2007, 20:46
Wohnort: Stuttgart
Kontaktdaten:

Beitrag von toxonic »

mhh, dann werde ich mich jetzt mal outen, die zweite vorhandene stimme hab ich abgegeben, muss aber zugestehen das ich da eher instinktiv gestimmt habe und nicht so weit nachgedacht habe! mir gings erstmal um die ganzen, teilweise sehr schicken ensmbles in der ul und jene, die ich selbstentworfen habe, die dann mit ziemlicher sicherheit nicht mehr laufen würden.... desweiteren bin ich noch nicht allzulang reaktor user, das erlernen des programms bis zum heutigen tag war recht zeitintensiv....da ich ja ein fauler strick bin, will ich mich nicht zwingendermassen in ein komplett neues reaktor nochmals einarbeiten!
nunja, nichts desto trotz geb ich euch beiden recht, es gibt einen haufen ungereimtheiten und bugs bei manchen aktuellen modulen und die vorschläge von herw klingen durchaus angebracht und überdacht!
naja, sollte vielleicht nicht so schnell aus der hüfte schiessen... :lol:
magneton
synth doctor
Beiträge: 263
Registriert: 17. April 2006, 13:00
Wohnort: mannheim

Beitrag von magneton »

hmm. jetzt muss man hier auch noch seine meinung abgeben (an anderer stelle wollen sie mein alter wissen...).
na gut:
reaktor 6 interessiert mich nicht.
wenn er dann erscheinen sollte, ist immer noch zeit sich damit zu beschäftigen. die katastrophe mit den ersten megabug versionen von r4 habe ich immer noch nicht vergessen.
ich persönlich entdecke bei intensiver beschäftigung immer neue sachen, die ich mit dem vorhandenen reaktor (nummer egal) machen kann.
Benutzeravatar
KlangRaum
synth guru
Beiträge: 647
Registriert: 1. August 2006, 12:55

Beitrag von KlangRaum »

eine abwärtskomp. sollte imho erhalten werden, damit ALLE bisherigen ensembles auch weiterhin eingesetzt werden können.
bugs sollten beseitigt werden .... ist ja wohl logo™ ;)

aber:
sollte sich bei bereits etablierten modulen ein bislang "toleriertes" fehlverhalten herausstellen und eine korrigierte version ihrerseits nicht mehr sicherstellen kann, das bisherige ensembles damit noch einwandfrei funktionieren.... dann sollte das betreffende modul quasi eingefroren und nur noch rein funktional beibehalten werden. gleichzeitig sollte ein entspechendes fehlerfreies v2.0-modul angeboten werden

(kann sich noch jemand an den alten 2-fach schalter erinnern? der wird ja mittlerweile eigenlich ganz geschickt übersetzt....)

oder...

man sollte aber auch mal die chance mit core&co nutzen.... das sich evtl alle bisherigen primary-module einfachst als core öffnen (umkompilieren?) lassen ohne das sich bei diesem vorgang auch nur ein einziges detail and der ensemblefunktionalität und am klang verändert....
das umzusetzen wäre eigentlich eine megaaufgabe für NI

wenn ich heute reaktor uppe... uppe ich irgendwas ohne zu wissen, was dann hinterher stattdessen nicht geht. besser wäre es, einzelne module zu uppen und diese aber in einer art repository zu parken

reaktor hat sich in all den jahren von einem synthbaukasten zu einem komlexen werkzeug entwickelt. manchmal glaube ich, das einige user das eher bemerken, als NI es tut ;)
Siggi Natur ? :mrgreen:
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Beitrag von herw »

KlangRaum hat geschrieben:eine abwärtskomp. sollte imho erhalten werden, damit ALLE bisherigen ensembles auch weiterhin eingesetzt werden können.
bugs sollten beseitigt werden .... ist ja wohl logo™ ;)

aber:
sollte sich bei bereits etablierten modulen ein bislang "toleriertes" fehlverhalten herausstellen und eine korrigierte version ihrerseits nicht mehr sicherstellen kann, das bisherige ensembles damit noch einwandfrei funktionieren.... dann sollte das betreffende modul quasi eingefroren und nur noch rein funktional beibehalten werden. gleichzeitig sollte ein entspechendes fehlerfreies v2.0-modul angeboten werden
...
ja das ist eine gute Idee; im Prinzip - aber dann werden diese alt hergebrachten "unstimmigen" Module auch weiterhin benutzt; Beispiel: diese ständigen Widersprüche und Klimmzüge über die Einteilung von Panelelementen (siehe den Thread zu IC-send aus dem diese Befragung entstand).
Nein ich denke man (NI) muss darüber nachdenken, welche Elemente sich aus der Tradition von REAKTOR und REAKTOR SESSION noch gehalten haben. Sind es wirklich so viele Ensembles, die eine Umstellung betreffen werden?
Ich denke, dass kritische Module schon längst durch workarounds von den etablierten Ensemble-Gestaltern gemieden oder umgangen werden. Und Ensembles, die bestimmte (eigentlich unkorrekte) Modulverhaltensweisen bewusst nutzen, braucht man nicht durch Kompatibilität zu fördern.
NI sollte allerdings diese Module rechtzeitig bekanntgeben und vorübergehend einen workaround anbieten, den man nach Veröffentlichung von R6 direkt durch ein entsprechendes Modul und einen Automatismus beim Abspeichern ersetzen kann.

Ich denke auch nicht, dass wirklich so viele Ensembles aus der Kompatibilität herausfallen werden:
Ich stimme für ein generelles Aufräumen, Unstimmigkeiten zwischen bestimmten Modulen müssen weg, auch wenn dann einige Ensembles nicht mehr laufen; bei wichtigen Ensembles (wie viele werden das sein? vielleicht zweihundert) muss man über eine Nachkorrektur von Hand nachdenken.
Was ich nicht möchte, ist, dass REAKTOR sein Konzept der graphischen Programmierung über Bord wirft und zu einer reinen Programmiersprache wird, aber ich denke, das will niemand, dann könnte man gleich auf andere Programme ausweichen.
Ich stimme für einen radikalen Schnitt.

ciao herw
helmsklamm
synth gott
Beiträge: 1011
Registriert: 10. Mai 2006, 16:21
Wohnort: 030

Beitrag von helmsklamm »

ich glaub auch, das klangraums vorschlag zwar verlockend klingt, aber eben doch nur zu faulen kompromissen führt. (windows krankte ewig, bzw. kränkt noch immer an seiner dos-kompatibilität - oder anders rum: das bios wird es eben nich in V2 geben, sondern komplett neu gestaltet, ohen rücksicht auf altlasten, was der einzig richtige weg ist).

irgendwann kommt eben in jeder technologie der punkt, wo eine komplette neuentwicklung angeraten scheint, und das produkt dann nich bspw. PCI 2 sondern PCI-X heisst. (ok, im bsp. trifft das idR eher AGP anstelle PCI, aber ihr wisst was ich meine).

was die UL betrifft: weiviele der ens dort sind A "redundant" und haben B bestenfalls noch nostalgische qualitäten? ich denk mir die entwickler guter, aktueller ups würden ihre ens, sofern sie nach dem up noch ne lücke schliessen oder anderweitig wichtig sind, ihre teile auch freiwillig portieren.
(schon alleine um die neue spielwiese kennzulernen) sinnvolle tools wie ne skalenkorrektur oder universalmixer oder sidechain-kompressor wirst du wahrscheinlich schon in der ersten woche dort erneut finden. und wahrscheinlich robuster und besser performant als zuvor.
auch wenn villeicht im ersten halben jahr das eineandre instrument schmerzlich vermisst werden, es werden schneller als erträumt trohnerben folgen, die höchstwahrscheinlich allesamt besser als ihre vorgänger sind. solange kannst du ja alternativ mit R5 rumgurken, wo ist das problem?

und das du deine macros erstmal händisch anpassen musst, naja kostet halt 1,2 nachmittage aber das wars. das du dein ensemble neu strukturieren musst - he, das machst du doch sowieso, wenn neue module erscheinen (herw bspw. "portiert" sein haupt-teil doch auch ohne "zwang" auf die neuen möglichkeiten von R5, ganz freiwillig sogar.)
bitte vor jeder frage erstmal überprüfen, ob das kapitel "mein erster synth" S. 76 im hnadbuch, schon gelesen wurde.
helmsklamm
synth gott
Beiträge: 1011
Registriert: 10. Mai 2006, 16:21
Wohnort: 030

Beitrag von helmsklamm »

ach und nochwas zur "skriptsprache":

(ich gebe aber zu bedenken, das hier ein einäugiger eher "glaubensätze" als empiriken postuliert)

core ist doch bereits ne skriptsprache. (auch wenn konsolen-fans das anders sehen;)) und ich glaube auch keine schlechte. vielleicht is sie nich ganz so mächtig wie C++ oder neuerdings D, mit sicherheit aber mit sachen wie visual basic oder was es sonst so gibt in gleicher liga spielend (natürlich bislang rein auf audio spezifiziert, aber das heisst ja nicht, das das so bleiben muss). weswegen core aber bislang n schattendasein fristet, liegt mE am "schlechten" compiler, bzw. den fehlenden "echten" assemblern. es gibt kein garbage collector, kein automatisches "lazy", keine maschinenblinde kommentare, etcpp. core kennt ausserdem weder sse noch altivec. mit der folge, das die ohnehin schlechte ni-performance nochmals DEUTLICH mehr saft benötigt.
warum soll ich mir n hp-filter bauen das bei gleichen klang doppelt soviel frisst?
ich denk mir, core is per se ein gutes skript, allerdings sollte auf jeden fall die "hochsprache", vor allem aber an der übersetzung gearbeitet werden. hier könnte uU ne inkompatibilität zwischen den plattformen auftreten, dh. ein mac-optimiertes teil is für windoof nich lesbar und vice versa. da jetzt aber beide auf x86 prozzies zugreifen, dürfte es demnächst irrerelevant sein.
inwiefern das OS noch ne rolle spielt mag ich nich zu beurteilen, aber dem prozzi is es schlussendlich egal ob er wrangler oder levis trägt, nur sollten beide passen. natürlich kann jedoch hier die handbremse liegen, aber vor allem wichtig ist, das der compilier/assembler die "hochsprache" dem prozzi so effizient wie möglich, unter ausnutzung seiner "stenografie" (bspw. SSE4), "übersetzt".

gut möglich, das hier trotz meiner obigen "thesen", das OS und die direktere umgebung, die "ENGINE", einige äusserst gewichtige worte mitsprechen wollen und schlussendlich den flaschenhals bilden. im falle core scheint dies aber nicht der fall zu sein. (siehe hp -beispiel) hier wird ganz offensichtlich, das der core interene compiler die echte performance brmense ist. tja, solange sich da nix ändert wird core weiterhin nich gerade sexy wirken. (abgesehen von spezillen event-eventualitäten). gutgut, die fft sachen mal aussen vor, aber ehrlich: zu welch exorbitanter cpu werden die erkauft?

wir sehen: son allerwelts"compiler" wie im falle core mag zwar plattformunabhängig sein, aber schlussendlich is dat dingens grottenschlecht performant. gewissermassen is die reaktor-"prim"-engine ja auch nix andres als ne (legoland) skriptsprache, performance-wunder darf man sich hier also nich erwarten. wo wird dein ensemble compiliert? eben.
ein enduro kann zwar auf ner aspahltierten strasse, wie im gelände fahren, aber es findet hier und dort seinen meister. hybrid UND spezialisiert geht nicht.
was bedeutet das? ich bin mir nicht wirklich sicher, aber schlussendlich doch, das es entweder A nur performance oder B nur unabhängigkeit geben kann, beides zusammen ertsmal nicht. es sei denn NI reicht nen crossform-compiler nach, der auch plattformübergreifend arbeitet. nun kann selsbts der beste compiler natürlich nur erahnen, was du wirklich willst, in der praxis bringt er aber gutgerne 60%. echte qualitäts-programmer gehen ihren code danach nochmal zeile für zeile durch und holen tatsächlich nahezu 100% raus. (die %zahl entspricht keineswegs der relation: während der code so vielleicht 12 minuten dauert, könnte der compilierte part nur noch 8 sekunden dauern. per hand optimiert aber nur noch 0.2 sekunden).
ich mutmasse mal: core is nich schlecht performant, weil es ein grafisches skript ist (letzendlich wird auch das in binärcode übersetzt), sondern weil der compiler/assembler noch deutlich luft hat, was vielleicht auch an seiner "echtzeit" natur liegt. vielleicht sollte man hier noch nen "richtigen" compiler nachlegen, der eben nicht in echtzeit und aus reaktor heraus arbeiten kann, sondern den ich händisch auf OS ebene bemühen muss. der dafür aber ordentlich was bringt.
aber wie gesagt, das sind nur laien-vermutungen.
bitte vor jeder frage erstmal überprüfen, ob das kapitel "mein erster synth" S. 76 im hnadbuch, schon gelesen wurde.
Benutzeravatar
KlangRaum
synth guru
Beiträge: 647
Registriert: 1. August 2006, 12:55

Beitrag von KlangRaum »

helmsklamm hat geschrieben:ich glaub auch, das klangraums vorschlag zwar verlockend klingt, aber eben doch nur zu faulen kompromissen führt. (windows krankte ewig, bzw. kränkt noch immer an seiner dos-kompatibilität - oder anders rum: das bios wird es eben nich in V2 geben, sondern komplett neu gestaltet, ohen rücksicht auf altlasten, was der einzig richtige weg ist).
man sollte reaktor lieber nicht mit dos/windoz vergleichen ;)

warum faule kompromisse?

wenn man mal als beispiel "richtige" programmiersprachen betrachtet, die über eine wirklich modulare bibliothek verfügen, dort klappt das aber mit dem prinzip library-repository. NI müsste sich eben zu einem gewissen schritt entscheiden..... bislang ist ja jedes primarymodul eine art black-box im innern von reaktor. könnte man die alle per klick in core konvertieren, wäre schon mal viel getan....
das bedeutet aber auch, das die GUI ind das ganze handling drumherum ebenfalls ein bestand von core werden müssen. da wäre uU ein scriptansatz durchaus vernünftig.....
Siggi Natur ? :mrgreen:
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Beitrag von herw »

KlangRaum hat geschrieben:... könnte man die alle per klick in core konvertieren, wäre schon mal viel getan....
das bedeutet aber auch, das die GUI ind das ganze handling drumherum ebenfalls ein bestand von core werden müssen. da wäre uU ein scriptansatz durchaus vernünftig.....
liest man sich die Stellenangebote von NI durch, dann könnte man jetzt spekulieren:
NI jobs.gif
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
KlangRaum
synth guru
Beiträge: 647
Registriert: 1. August 2006, 12:55

Beitrag von KlangRaum »

software-installer :?: :lol: :lol: :lol: :lol:
das klingt wie ein job, den ich mal hatte.... den ganzen tag auf ne buggy software buggy bugfixes draufbügeln... bis der pc neu installiert werden musste. war halt windoz live.

(soooorry.... 8) konnte jezz nich anders)
Siggi Natur ? :mrgreen:
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

schweigende Mehrheit

Beitrag von herw »

die schweigende Mehrheit (90%); wenn man Einfluss nehmen möchte, dann sollte man seine Stimme abgeben, auch wenn unser Forum nur sehr klein ist. Auf sieben Meinungen kann NI nicht reagieren!
Also stimmt ab!
Antworten