Deutsches Reaktor Forum

das "programieren" in reaktor und "echter" sprachen untescheidet sich ja (neben der grafischen komponente) hauptsächlich darin, das reaktor ne virtulle maschine (VM) bereiststellt, die aufwendiges "externes" (=non-echtzeit) kompilieren "überflüssig" macht.
das bietet natürlich jede menge vorteile, insbesondere für leutz die ihre sachen "heuristisch" zusammenschustern. die jederzeitigige überprüfbarkeit eines gedankens, bzw. das "on-the-fly-debuggen" sind ein echter segen.
auch die relative großbausteinigkeit (prim-ebene) oder besser: universialität der module dürfte in der praxis fast ausshclisslich eher begrüßt als als nachteilig empfunden werden.
demgegenüber steht zwnagsläufig ne schlechtere performace als bei "massgeschneiderten" dingen: ungenutzte ein/ausgänge (oder optionen - die intern ja auch nur "switches" /resp. derzeit ungenutzte alternativ-"module" sind) bleiben defacto erhalten, auch wenn sie temporär blind sind. mit andern worten: sie verbrauchen mindestens speicher. denn alles was "da" ist, nimmt raum, egal ob es was sagt oder schweigt.

in ner "richtigen" sprache wird "extern" kompiliert und nach diesem vorgang sind bestimmte sachen, für die maschine nicht nur nicht sichtbar sondern defacto auch tatsäschlich nicht mehr vorhanden. bspw. könntest du in C hinter jeder zeile "nutz-code" nen romanlangen kommentar schreiben (jedes zeichen benötigt mindestens ein bit! - das kann sich also summieren) und nach dem compilen wäre dieser tatsächlich nicht mehr (in der "maschinen-version", sprich: deiner .exe) vorhanden.

ne VM ist natürlich grundsätzlich anders konzipiert: hier gehts nicht um optimale ergebnisse, sondern um gröstmögliche kompatibilitäten. es wird also im vorraus jede menge offener speilraum gelassen um für größtmögliche enventualitäten gerüstet zu sein. bei nichtnutzung des speilraums tritt mindestens der seiteneffekt unoptimierten, d.h. das heisst nichtbenutzen aber trotzalledem vorhanden sein müssenden, speichers ein. um diesen unerwünschten effekte so weit wie möglich herr zu werden, glaube ich schon, das NI dahingehend größtmögliche soragfalt hat walten lassen - bspw. verwalten viele module ihren bedarf dynamisch (das SVA klagt erst bei neuen arrays/snaps mehr speicher ein, jegliche form von "weichen" - router, selector... werden per default in ihrer "spar-version" aufgerufen, acuh die beshränkung auf 40(?) in/outs dürfte dahingehend begründet sein, und dutzend weitere sachen.

trotzdem bleibt ne VM wie das reisegepäck der meisten frauen: obwohl fest steht, das man nen natur-urlaub machen will, wird trotzdem vorsichtshalber der halbe "party"-kliederschrank eingetütet. nun, im auto frisst das nur "speicher", beim echten rucksackschleppen is das schon unangehnemer.

das beispeil hinkt. die meisten module dürften schon "eventualitäten-durchdachter" als die meisten rücksäcke sein. trotzdem verbleibt n "lieber mehr als weniger" kerngedanke. und das ist auch gut so (bspw. brauchte ich neulich n order-modul mit 4 ausgängen, hier war also der gegensätzliche fall zu beobachten).

was ich sagen will ist:
echtzeit-kompilieren ist ein wahrer segen. hochperformance wird aber nur durch "extern" kompilierung erreicht. warum alos nicht beide sachen verbinden?

in der "arbeitsversion" wird nach wie vor in echtzeit kompiliert, diese benötigt die VM. Ist diese zufriedenstellend und bugfrei kann ich sie in echte machienensprache übersetzen lassen - natürlich non-echtzeit, aber heirbei wird gründlich ausgemistet: alles was die die "maschine" nicht braucht, wie kommentare, unbenutze ports, "optionen"-module, vergessene test-routinen (bspw. endziel numeric ohne echte weiterverdrahtung), ja, die ganze struktur-gui (die der maschine ebenfalls völlig egal ist)... wird konseqeunt rausgescmissen. in die exe gehört ausshliesslich "nutz"-code.
solltrest du nach dem "echten" kompilieren unstimmigkeiten festtellen - hast du deine arbeitsversion und sofern der compiler nich spinnt, findets du den fehler dort, fixt ihn dort und kompilierst erneut.

helmsklamm hat geschrieben:...in der "arbeitsversion" wird nach wie vor in echtzeit kompiliert, diese benötigt die VM. Ist diese zufriedenstellend und bugfrei kann ich sie in echte machienensprache übersetzen lassen - natürlich non-echtzeit, aber heirbei wird gründlich ausgemistet: alles was die die "maschine" nicht braucht, wie kommentare, unbenutze ports, "optionen"-module, vergessene test-routinen (bspw. endziel numeric ohne echte weiterverdrahtung), ja, die ganze struktur-gui (die der maschine ebenfalls völlig egal ist)... wird konseqeunt rausgescmissen. in die exe gehört ausshliesslich "nutz"-code.
solltrest du nach dem "echten" kompilieren unstimmigkeiten festtellen - hast du deine arbeitsversion und sofern der compiler nich spinnt, findets du den fehler dort, fixt ihn dort und kompilierst erneut.

aus Deiner (Entwicklers) Sicht völlig ok - aber was macht der User, der Dein Ensembles sich heruntergeladen hat und manche Passagen kopieren möchte. Alles muss immer wieder neu kompiliert werden und die Module-Bibliothek wird unüberschaubar. Bei der Analyse und Diskussion von Strukturen müsste man sich zunächst einmal über die Eigenschaften der Spezialmodule unterhalten. Das hemmt jede Pro-Kontra-Rede und die Kommunikation schläft ein.
So sehr ich Deinen Wunsch verstehen kann, das finde ich angesichts vieler schlecht strukturierter Ensembles unzumutbar. Ich weigere mich schlicht, eine Frage zu einem Chaosensemble zu beantworten.
Wenn Du Spezialanfertigungen von Modulen erstellen möchtest, dann müssten sie in die allgemeine Bibliothek übernommen werden und auch entsprechend beschrieben und klassifiziert werden.
Wie oft wird denn schon über NIs Handbuch gemeckert, dass es nicht genau genug die Eigenschafetn beschreibt.
Das Weglasssen eines nicht benötigten Moduleingangs ist eine Sache, aber ein neues Modul zu erfinden und zu dokumentieren eine andere.
All dies ist aber doch trotzdem durch die Core-Ebene möglich gemacht. Auch wenn die Core-Ebene nur ein Angebot der REAKTOR-Entwickler ist: es ist eine Aufforderung zu: dann zeigt doch mal, was ihr verbessern wollt. Das sollten wir wahrnehmen.
Wer ein tolles neues Modul erfindet, kann es in der FUNDGRUBE vorstellen und bewerten lassen. Dabei kann man sich auch einfach eine Erweiterung eines Moduls vorstellen, das die Standardvorgaben schon beinhaltet (ich denke da zum Beispiel an das SVA-Modul mit seinen Indizierungen)
Vielleicht könnte man es nach einer Diskussion in eine interne Bibliothek hier übernehmen und für eingetragene Mitglieder zugänglich machen.

ciao herw

du hast mich falsch verstanden: ich rede von 2 versionen. deiner arbeitsversion mit vollem strukturzugriff etc. und ner "spiel"version, die zwar nicht mehr bearbeitbar ist, dafür aber perform-optimiert.

erscheint dir die "alte" version nach nem halben jahr oder so erweiterungswürdig greifst du eben zu deiner progress-version und bastelt darin solange rum bist du meinst "vorübergehend fertig", renderst das teil, musizierst n halbes jahr damit und alles beginnt von vorn.


aber unabhängig davon, finde ich deinen "bibliothek" vorschlag süpi. (leider geht grade das sva nicht - du kennst die core1 beschränkung von wegen: flüchtiger speicher vs. fester.)
aber prinzipiell is die idee knülli - ich stelle mir ne art "wünsch dir was" vor und wer zeit/lust hat arbeitet dran und nur wer mitgearbeit hat (generell - ob nun an dem konkreten teil oder einem früherern, auch wenns nur wortbeitrag oder n link war) darf sich das teil dann auch downen - als anreiz für die dsp-faulen unter uns.
jo, ich denke das bringt sowohl didaktisch als auch praktishc was.

du meinst also wie das standalone prinzip von max/msp (also eigenständig ohne max/msp lauffähigerprogramme) oder die pluggo-idee?

seh ich gespalten. einerseits ist da der performance vorteil.
andereseits seh ich aber auch das probelm, dass dann die userlibrary immer weniger als prinzip funktionieren würde (außer das standalone-app ließe sich wieder problemlos zurück verwandeln)

@helmsklamm: du meinst bestimmt so eine art optimierenden compiler, der evtl zusätzlich noch ein standalone aus dem ensemble macht.....
machbar wäre es, aber ich bin mir nicht sicher, ob NI aus lizenzrechtlichen gründen sowas haben will

nq/kg: jo, so meine ich das: 2 versionen - eine ist jederzeit bearbeitbar, benötigt aber demzufolge die VM (reaktor) und das andere ist ne kompilierte exe, nicht bearbeitbar aber höchstwahrscheinlich performanter.

ok, thema UL sprengt hier zwar den rahmen aber diskusionswürdig ist es allemal. (vielleicht hier trennen? und neuen fred??)

was die UL betrifft - stimmt, da dürften einige (namentlich die "reaktor session" front) enttäuscht sein, denn ganze enembles werden dann wohl nicht mehr so oft geupt. trotzdem glaube ich nicht, das unter den entwicklern, und ich wiederhole den ENTWICKLERN der austausch einschlafen wird. im gegenteil: mit dem wissen im hinterkopf, mitglied einer AKTIVEN gemeinschaft zu sein, in welcher das GEBEN von JEDEM teilnehmer als persönliche ehrensache betrachtet wird, dürfte die bereitschaft eigene beiträge "JEDEM" zugänglich zu machen erheblich steigern.
mit eigene beiträge meine ich jetzt nicht so gigantische bauklötze wie ganze ensembles, sondern eher isolierte problemlösungen oder etwas großflächigere "blaupausen" für ne verblüffende nutzungsmöglichkei, oder ähnliches (entweder kreatives oder auch arbeitsintensives wie ne handgeschriebene sinus-tabelle) - es is doch schon heute so, das ambitionierte entwickler sich zwar ganze enembles downen, davon aber vielleicht nur 1 macro rippen, oder lediglich verdrahtungs-tricks studieren.

was passiert nun mit den ganzen ensembles? wer will könnte sie natürlich nach wie vor in der UL den leechern servieren. wer glaubt, das seine arbeit es verdient, auch früchte einzubringen - nun, der kann es selbstredend versuchen zu veräussern. entweder alleine oder im verbund mit anderen entwicklern unter gemeinsamer flagge. explizit letzteres halte ich für nen sehr spannenden weg, der zudem die gesamte entwicklung ungemein nach vorne peitschen dürfte.
nehmen wir an, 5 entwickler schliessen sich zusammen, mit dem ziel in bissl gemüse in die kombüse zu bekommen. sie basteln also ne website und rühren gemeinsam die werbetrommel. jeder der 5 steuert mindestens ein "ensemble" bei (oder macht anderweitig wichtige sachen bspw. qualitätskontrolle oder grafik, schreibt manuals....). wie gesagt, eint sie ein ziel: n bissl geld zu verdienen und hervorragende "ensembles" zu basteln.
nun gibt es höchstwahrscheinlich einige dieseer "schmeiden". und sie stehen auch in gesunder konkurenz zu einander. und exakt das dürfte der schub nach vorne sein:
woran krankt die UL am meisten? an lieblosen, reduntanten, verbugten, undurchsichtigen.... teilen. - was nützen einem > 2000 ensembles, wenn der prozentsatz brauchbarer weit unten im einstelligen prozentbereich liegt?

wenn nun für etwas (auch wenig) gezahlt werden muss, kann man den leuten selbtredend immer noch dreck vorsetzen - ein 2tes mal aber kaufen sie ganz sicher nicht bei dir. die qauntität der ensembles wird abnehmen aber die qualität dürfte höchstwahrscheinlich indirekt proportional steigen.
und das ist wohl die hauptsache.

ok, bleibt der faktor "konkurenz" und des "code-offenlegens". ich denke, der "code" wird trotz der "konkurenzhaftigkeit" weiterhin offengelegt, allerdings mit nem kleinem delay. gruppe A wird erst ein pfigges macro (code) entwickeln, dann versuchen es in ihrem produkt zu veräussern aber nach ner gewissen "vorsprungspahse" es schleisslich der gesamten gemsinschaft ohne einschränkung offenlegen. denn genau das erwarten sie auch von gruppe B,C.... und dieses ihrerseits betrchten es ehrensche, der erwatung gerecht zu werden (selbstredend auch "verzögert").
es entshet also ne art "verspielter", sich gegenseitig zu höchstlesitungen anspornender und inspirierender "konkurenz", in der A uU vielleicht n bisschen gewurmt ist, das B die idee zuerst hatte, aber sich nichtdestotroz für B freut und das als anreiz sieht es B "heimzuzahlen" (= noch besser als B zu sein, ergo neue qualitätslatte) .
man könnte einwenden, diese art "konkurenz" gibt es ja bereits schon. stimmt. allerdings auf hobby-niveau. die bereitschaft zeit in etwas zu investieren hängt auch ganz entschieden von der art der entlohnung ab: wenn du nur n "thx" bekommst, dürfte sie geringer sein, als wenn du tatsächlich damit auch deine grundbeürfnisse finanzieren könntest.
qualitätssteigerung hängt kausal mit professionlaisierung zusammen.

schlussendlich profitieren sogar die leecher davon. zugegeben - vieles wird es nich mehr für lau geben. aber das höhre niveau der sachen sollte das mehr als aufwiegen. (für EIN bugfreies, gui-verständliches, manual-begleitetes ensemble geb ich gerne mehr geld aus, als für 1000 absürzende, undurchschaubare, hingeshluderte teile).

der einzige, der sich als verleierer sehen könnte, wäre NI. doch halt: warum nicht wie früher ne 2teilung im reaktor-portfolio? diesmal aber zugunsten der entwickler und nicht der leecher:
in reaktor-standard (analog zur jetzt-version) und reaktor-entwickler (diese dürfte ruhig doppelt so teuer sein, auch NI soll schliesslich was davon haben, dafür liesse sich aber nur mit ihr ne echte .exe rendern).

das klingt villeicht alles n bissl blauäugig, aber echtes opensource funzt ähnlich, und: es funzt! und zwar schon jahrelang!! und das sogar süpi!!!

soweit der grundgedanke. sehr roh, sehr unausgereift... vielleicht scheinbar widersprüchlich, blauäugig --- trotzdem halte ich das für sinnvoll und für ne win-win-win gescchichte. und mit der denkkraft einer vielköpfigen gemeinschaft ist sowas auch rund zu kriegen.