SynC Modular

[Rampensau]

Gerade schlage ich die Beat auf, die ich eigentlich abbestellen wollte, und erhalte eine Seriennummer für die Anwendung SynC Modular von NI.

Der Reaktor-Vorläufer ist nun als Freeware freigegeben.

January 11, 2010
SynC Modular is made free to the public by Native Instruments

Quelle:
http://syncmodular.com/

[Rampensau]

sehe gerade. ist windows only. aber für eingefleischte Reaktorianer eh uninteressant, wie?

[Rampensau]

Okay. Das ist ja auch nicht wirklich ein Reaktor-Vorläufer.
Wie ich das verstehe, ist das ein "Vorfahre" der Core-Ebene.

Jedenfalls schön, dass das Programm einer breiteren Masse zugeführt wird. Die Leute werden vielleicht endlich merken, dass die core-artige Programmierung einfach Spaß macht.

[herw]

Okay. Das ist ja auch nicht wirklich ein Reaktor-Vorläufer.
Wie ich das verstehe, ist das ein "Vorfahre" der Core-Ebene.

Jedenfalls schön, dass das Programm einer breiteren Masse zugeführt wird. Die Leute werden vielleicht endlich merken, dass die core-artige Programmierung einfach Spaß macht.

Ist nicht der Entwickler vom Sync Modular der Erfinder der Core-Ebene in REAKTOR?

[Rampensau]

Ist nicht der Entwickler vom Sync Modular der Erfinder der Core-Ebene in REAKTOR?

Jupp! Dr. Sync alias Vadim Zavalishin.
Seinerzeit war er wohl noch nicht Entwickler bei NI. Der SM hat NI wohl so gut gefallen, dass sie dessen Programmierer eingestellt haben, eine Art Sync Modular für Reaktor zu schreiben.

Nun ist der SM zwar kein Standalone-Core, dafür fehlen ihm ein paar Module. Er hat aber schon ein wenig mit Core gemein.

Nun frage ich mich aber: Warum macht NI das mit der Freistellung? Und warum gerade jetzt?
Und was ich mich noch frage: Was kommt in Reaktor noch alles auf uns zu? Code? Und wie wollte man die Core-Ebene noch weiter ausbauen? Mir kommt sie im Moment noch ziemlich vollständig vor.
Ist das spannend...

[Rampensau]

Ich bin jetzt gerade am Testen. Und ich habe schon einen interessanten Sinus-Algorithmus gefunden, mit deutlicher CPU-Ersparnis gegenüber der Polynomverzerrung. Ich bin gerade am "Übersetzen" in Reaktor. Vielleicht entdecke ich ja noch mehr hübsche Sachen.

[herw]

Ist nicht der Entwickler vom Sync Modular der Erfinder der Core-Ebene in REAKTOR?

Jupp! Dr. Sync alias Vadim Zavalishin.
Seinerzeit war er wohl noch nicht Entwickler bei NI. Der SM hat NI wohl so gut gefallen, dass sie dessen Programmierer eingestellt haben, eine Art Sync Modular für Reaktor zu schreiben.

Nun ist der SM zwar kein Standalone-Core, dafür fehlen ihm ein paar Module. Er hat aber schon ein wenig mit Core gemein.

Nun frage ich mich aber: Warum macht NI das mit der Freistellung? Und warum gerade jetzt?
Und was ich mich noch frage: Was kommt in Reaktor noch alles auf uns zu? Code? Und wie wollte man die Core-Ebene noch weiter ausbauen? Mir kommt sie im Moment noch ziemlich vollständig vor.
Ist das spannend...

Die Freistellung erfolgt sicherlich deshalb, weil der SyncModular einfach keine Konkurrenz mehr für REAKTOR ist und um vielleicht über diesen Umweg noch einige mehr für REAKTOR zu interessieren. Vadim war (und ist immer noch) der Ideengeber für Core.

Die Core-Ebene kann man noch gewaltig ausbauen. (meintest Du tatsächlich „vollständig” oder war das ein Fingerlapsus?)
Dabei sehe ich drei Notwendigkeiten:

1. Basis-Module
   • from / to voice
   • order
   • interne Verbindungen
   • globale Variablen
   • gemeinsame Speicherfelder
   • iterator
2. Ausgereifte Varianten einiger Grundmodule
   • Hüllkurven
   • richtige FM-Oszillatoren
   • Resonatoren wie in absynth
3. Komplexe Module

• habe ich wenig Ahnung, aber es gibt ja diverse Wunschlisten im englischen Forum. Das Problem ist, dass nur sehr wenige überhaupt verstehen, was in diesen Modulen wirklich vorgeht. Solche Module zu entwickeln, kostet sicherlich viel Zeit, die user interessiert dann nur noch das Endprodukt, das dann wiederum auch wieder sehr komplex ist und damit nur in einer Anwendung, einem speziellen komplexen Ensemble endet.
  
  Krümelmonster (Gerald List) kann dir noch zig andere gehaltvolle Wünsche vortragen.

Man darf dabei nicht das Ziel von NI aus den Augen verlieren: wenn man über mehrere Jahre die Entwicklung dieses Unternehmens verfolgt, so kann man erstaunt feststellen, dass es von einem kleinen Entwicklungslabor Ende der neunziger Jahre zu einem ansehnlichen mittelständischen Unternehmen mit etwa 180 (!) Mitarbeitern angewachsen ist.
Das heißt, dort liegt ein nicht zu unterschätzendes attraktives unternehmerisches Ziel. Größere Nutzergruppen müssen angesprochen werden. Die Core-Ebene ist vielen ein Gräuel - unverständlich, da core in sich (fast) völlig logisch und einsichtig aufgebaut ist.
Tutorials sind nötig, um (auch einfache) Kreativität zu fördern.

Auf der primary-Ebene fehlen mir immer noch einige Schmankerl: Zugriff auf internal connections über das Panel (Signal-Buchsen wie im Modular), midi-learn für Maus-Steuerung und was ich genial fände: eigene Hardware-Entwicklungen für REAKTOR (ausbaubares Modularsystem).

In welcher Art und Weise NI REAKTOR weiter entwickeln wird, ist leider für uns Nutzer ein Geheimnis; NI hält sich immer sehr bedeckt, wenn es um REAKTOR geht. Die Vorschlagslisten sind lang, NIs Andeutungen leider immer nur kurz und auch oft zeitlich verschoben.
REAKTOR scheint sehr komplex in der Programmierung zu sein. Zu viele Baustellen und Erwartungen haben sich in den letzten Jahren zu einem Aufgaben-Berg angehäuft, so dass man nicht mit einem Rundumschlag rechnen kann; das würde dann ja für gleich zwei bis drei Major-Updates reichen. Wichtig wäre es, dass die Zusicherung der stetigen Weiterentwicklung auch wirklich wie versprochen eingehalten wird.
Der Rückzug von Stephan Schmitt aus der Konzernleitung in die (reine) Entwicklung zeigt, wie wichtig, aber auch zeitintensiv nach wie vor REAKTOR ist.

[Rampensau]

Die Core-Ebene kann man noch gewaltig ausbauen. (meintest Du tatsächlich „vollständig” oder war das ein Fingerlapsus?)

Hihi, kein Fingerlapsus. Meiner "frechen" Ausdrucksweise folgte eine ausführliche Antwort deinerseits. So eine naive Fragestellung erhält meist mehr kompetente Antworten als gedacht. Ein bisschen Dummheit zu suggerieren, wird öfter von Erfolg gekrönt, als einem lieb sein mag.

Metaphorisch gesprochen: Angenommen man behauptet, dass die Schwerkraft blöder Humbug sei. Es gibt sofort ein paar Leute, die sehen wollen, wie man hinfällt oder einen sogar umschubsen.

Und dennoch habe ich Core immer als Ergänzung für den Primary-Level betrachtet. Es anders zu betrachten, macht ja auch Sinn, und lässt mich schon wieder an der "Vollständigkeit" von Core zweifeln.

* from / to voice
* order
* interne Verbindungen
* globale Variablen
* gemeinsame Speicherfelder
* iterator

Das zeugt auch von meiner tatsächlichen Unkenntnis von Reaktor. Ich hätte jedenfalls noch keine Vorstellung, was ich unter genannten Sachen verstünde oder gar mit ihnen machen könnte. Könnte man einen Iterator nicht schon in Core umsetzen?

Die Grundmodule jedoch kann man sich auch selbst in Core basteln, wenn man es kann. Das habe ich auch schon fast als meine Aufgabe als Core-Anwender angenommen. Außerdem wäre das ja weniger ein Core-Update, denn viel mehr ein Library-Update. Klar, ein Library-Update von den Machern höchst persönlich, würde das "Bauteile-Niveau" noch am besten steigern. Oversampling und akkurates Antialiasing sind mir jedenfalls noch ein Rätsel, obwohl ich auch da schon ein paar eigene Entwicklungen habe.

Oder fehlt es an Funktionen in Core, die es einem erst ermöglichen zB richtige FM-Oszillatoren oder Resonatoren zu bauen?

Ich würde mir auch gerne ein paar mehr Filter oder gar Polynome wünschen, aber deswegen tue ich im Moment auch viel daran, sowas in Core umzusetzen. Warum kann man sich selbst keine richtigen FM-Oszillatoren basteln?

Ich schweife mal ab. Der Rampenoszillator im Sync Modular ist echt genial. In den Eigenschaften kann man

• von Oszillator auf Hüllkurve umswitchen
• ein Antialiasing-Algorithmus hinzuschalten
• ganz schön viele Phasen/ Stages hinzuschalten
• jeder der Phasen als Sustain-phase festlegen

Die Anfangs- und Endpunkte, sowie Zeiten der Phasen sind per Regler (wie gewohnt) in Echtzeit definierbar.
Sowas für Reaktor wäre gar nicht so übel.

[herw]

* from / to voice
* order
* interne Verbindungen
* globale Variablen
* gemeinsame Speicherfelder
* iterator

warum sind hier einige Strichpunkte rot markiert?

Die Grundmodule jedoch kann man sich auch selbst in Core basteln, wenn man es kann.

from voice ist nur sehr schwierig zu realisieren, da aber ein to voice nicht funktioniert, ist ein entsprechendes Makro nutzlos. Order geht gar nicht oder nur mit asynchronen sample-rate-clocks (wurde hier schon ausführlich diskutiert).
Interne Verbindungen in Core würden übersichtliche und umfangreiche CoreCells ermöglichen, globale Variablen ebenfalls.
Gemeinsame Speicherfelder wie in Primary wäre genial, wenn man über weite Entfernungen Zugriff in Core haben möchte. Iterationen innerhalb eines Sample-Rate-Ticks sind gar nicht möglich.

[...]Oder fehlt es an Funktionen in Core, die es einem erst ermöglichen zB richtige FM-Oszillatoren oder Resonatoren zu bauen?

Nein da fehlt gar nichts, aber wer hat die Zeit und Energie das mal endlich zu verwirklichen?

Ich würde mir auch gerne ein paar mehr Filter oder gar Polynome wünschen, aber deswegen tue ich im Moment auch viel daran, sowas in Core umzusetzen. Warum kann man sich selbst keine richtigen FM-Oszillatoren basteln?

kann man, aber mach mal! - Schweinehund überwinden![/quote]
[...]

ciao herw

[Rampensau]

Die rot markierten Sachen wollte ich wohl ohne Erklärung erst nicht verstehen. Bei den anderen konnte ich mir schon vorstellen, was das ist.
Nun fällt mir auch ein, dass ich mir auch schon die ICs in Core gewünscht habe. Was aber sind globale Variablen oder gemeinsame Speicherfelder?
Ich habe viele Sachen im Primary noch gar nicht kennen gelernt.

Ich baue gerne ein paar FM-Oszillatoren, wenn ich mit dem Oszillatorbau-Projekt durch bin. Ich habe sogar schon eine Reihe an Modulen, die ich hochladen würde.
Was gehört denn zB zu einem richtigen FM-Osc?
Und Resonatoren sind doch auch bloß gestimmte Delays, oder!? Das krieg ich schon hin

Ob die dann auf höchstem Niveau sind oder doch nur Coreanfänger beeindrucken können, ist ja erstmal zweitrangig. Aber grundsätzlich ist der soziale Wille doch vorhanden.

Ich wühl mich demnächst mal durch die Wunschlisten. hihi.

[herw]

[...]
Ich baue gerne ein paar FM-Oszillatoren, wenn ich mit dem Oszillatorbau-Projekt durch bin. Ich habe sogar schon eine Reihe an Modulen, die ich hochladen würde.
Was gehört denn zB zu einem richtigen FM-Osc?
Und Resonatoren sind doch auch bloß gestimmte Delays, oder!? Das krieg ich schon hin
[...]

Richtige FM-Oszillatoren sind phasenstarr verbunden, damit bei jedem Ton auch die gleiche Klangfarbe entsteht. Das ist nicht schwer, aber muss man eben noch machen (Zeit ist REAKTOR).
Einen Resonator zu bauen ist im Prinzip nicht so schwer, das Problem ist die Stimmung. Wenn ich mich recht erinnere, ist es prinzipiell schwierig, eine Stimmung über mehrere Oktaven zu halten. Ich habe das schon vor einigen Jahren realisiert aber nie richtig ausgebaut. Da müsste ich ganz tief in eventuell noch vorhandenen Dateien und Verzeichnissen suchen.

ciao herw

[PrinzThomas]

Ist der Vorläufer von Reaktor nicht "Generator"?

[herw]

Ist der Vorläufer von Reaktor nicht "Generator"?

nicht ganz: Generator war REAKTOR ohne Transformator (alles was mit samplen zu tun hat).
Gemeint war hier aber die Core-Ebene, die mit dem alten SyncModular sehr ähnlich ist; kein Wunder der Entwickler von SyncModular wurde von NI „übernommen”.

[KlangRaum]

[...]
Ich baue gerne ein paar FM-Oszillatoren, wenn ich mit dem Oszillatorbau-Projekt durch bin. Ich habe sogar schon eine Reihe an Modulen, die ich hochladen würde.
Was gehört denn zB zu einem richtigen FM-Osc?

[...]

Richtige FM-Oszillatoren sind phasenstarr verbunden, damit bei jedem Ton auch die gleiche Klangfarbe entsteht. Das ist nicht schwer, aber muss man eben noch machen (Zeit ist REAKTOR).

Gibt ne Alternative dazu:
Die Yamaha-OPL verwenden ja Phasenmodulation, dadurch erspart man sich die Hochpassfilter am Modulationseingang -die braucht man wenn man einen OPL sch selbst modulieren lässt. (ansonsten entsteht durch einen „DC-Offset“ ein störender Frequenzversatz.)
Wir hatten dieses Thema schon mal, benutz mal die Suchfunktion mit dem Stichwort Phasenmodulation