Ich sehe gerade, dass meine kleine Frage eine Reihe von Antworten und neuen Fragen provoziert hat. Das war ehrlich als Frage gemeint, weil ich das Kronos Sampling einfach nur genieße und nicht auf Anhieb sehe, was mir anders von anderen Synths lieber wäre. Das File-System mit seinen Unterkategorien und die Verteilung von Sampling-Funktionen auf Disk-, Global und Sampling Modus war mir zunächst auch nicht gleich klar, als ich den Kronos neu hatte, aber inzwischen hat sich das geklärt und ist durch zwei Dinge m.E. für alle Kronos-User sehr gut handhabbar geworden:
a) wenn man es nicht als etwas abstrakt Technisches ansieht, sondern ein paarmal praktisch vollzogen hat, was man braucht, sind die Schritte weder allzu schwer zu verstehen noch durchzuführen
b) es gab ein entscheidendes Update, nämlich die Funktion „load required samples“, die meine einzigen „Umständlichkeits-Stolpersteine“ früherer Versionen beseitigt hat.
Am besten erkläre ich an praktischen Beispielen warum ich es jetzt so komfortabel finde. Ich hoffe, ich formuliere korrekt aus dem Gedächtnis, da ich gerade nicht am Kronos sitze. Ich rede dabei erst mal von Sample-Instrumenten (nicht von One-Shots etc., die direkt am Kronos aufgenommen und geloopt werden können).
1. Der Kronos lädt alle Sample Sounds, Factory und User, beim Start. Es gibt kein ROM, sondern ALLE Sounds im Kronos, Factory oder User (einzige Ausnahme ist die GM-Bank) lassen sich wahlweise hochfahren oder nicht. Das gilt für jedes einzelne Instrument.
2. Was hochgeladen wird, entscheidet man über eine Preload Datenliste. Diese Liste lässt sich sehr flexibel verwalten: man kann Unterbereiche (wie z.B. diejenigen Factory-Samples, die ich immer im Speicher will) in je einem großen Block zusammenfassen und anschließend durch Aktivieren oder Deaktivieren dieser Blöcke (Anklicken in der Preload-Liste) entscheiden, welche beim Start geladen werden. Man kann aber auch einzelne Instrumente so ablegen und für den Preload Kennzeichnen, je nachdem, was für den eigenen Überblick und die eigene Flexibilität besser ist.
3. Dieses System erlaubt es im Prinzip, komplett verschiedene „Kronoi“ hochzufahren: man könnte für eine Band und den entsprechenden Bedarf ein Preload-Paket auf SSD haben und für ein anderes Projekt ein anderes, die jeweils den kompletten Arbeitsspeicher mit dem ökonomischen Sample-Streaming nutzen können. Hat man einmal entsprechende Pakete definiert, kann man jederzeit für’s Hochfahren je nach Bedarf auf sie zurückgreifen.
4. Um Multisamples eines einzelnen Instruments aus einer fertigen Kronos-Bibliothek (Factory oder zugekauft) hinzuzufügen, kann man seit dem genannten Update einfach den Arbeitsspeicher leeren, ein PCG-Bank-File (das ist die oberste Ebene mit den Instrumenten-Definitionen) für diese Sample-Sounds laden, und dann von Instrument zu Instrument nach eigener Wahl „load required samples“ veranlassen. Als Ergebnis sind dann alle Samples im Arbeitsspeicher, die man weiter verwenden möchte (und nur die). Anschließend kann man diese Samples als Block-Datei (KSC/KMP) speichern. Wenn man dann veranlasst, dass dieser Block bei nächsten Start geladen wird, braucht man nur noch die entsprechenden PCG-Definitionen auf freie Bank-Plätze laden und kann auf die so vorhandenen, dazu passenden (Multi)Samples zugreifen.
5. Import von Samples, die nicht schon im Kronos-Format vorliegen, ist über das SF2-Format (viele Konverter konvertieren bei Bedarf in dieses Format) und das klassische ältere Akai-Format möglich.
6. Zur Erstellung von User-Samples verwendet man natürlich den PC: das geht theoretisch zwar auch direkt am Kronos, aber am PC mit den entsprechenden Tools wesentlich flüssiger. Mit Extreme Sample Converter z.B. (Preis unter 50€, wenn ich mich richtig erinnere) kann man mühelos eigene Hardware-Synth-Sounds oder sogar beliebige VSTis absamplen und dann im Kronos verwenden. Auch mit Kontakt kann man sich Instrumente für den Kronos bauen.
7. Inzwischen gibt es eine Reihe weiterer bequemer Tools für diesen Zweck, die aber teurer sind (Sample-Robot, Chickensys Translator und Constructor) und genauso gut direkt ins Kronos Format abspeichern wie als SF2s.
Was ich so komfortabel finde, sind vor allem folgende Punkte:
- freie und schnell wechselbare Verfügbarkeit über den gesamten Inhalt der Sample-Instrumente im Kronos (einzige Ausnahme die nicht allzu große feste GM-Bank) mit der Möglichkeit, jeweils innerhalb der üblichen Startzeiten von 3-4 Minuten völlig verschiedene riesige Sample-Bibliotheken je nach Zweck/Projekt/Band zu laden. In der Regel wird es auch möglich sein, sich ein maßgeschneidertes Paket für alle Zwecke in einer Startumgebung zu bauen, aber man muss nie Sorge haben, dass es nicht für alle Projekte reichen könnte.
- die Menge und Größe von User-Sample-Instrumenten, die man aus verschiedensten Quellen zusammenstellen kann, ohne Platzangst zu kriegen (dank User Sample streaming)
Das File-Sytem ist für mich also seit dem „load required samples“-Update überhaupt kein Stolperstein zur Zusammenstellung maßgeschneiderter eigener Instrumenten-Verwendung mehr.
Ich hoffe, das war einigermaßen verständlich.
Die Verwendung von Einzel-Samples und Audio-Files ist ein separater (und auch am Kronos sehr gut gelöster) Punkt, der aber glaube ich in dieser Diskussion nicht gemeint war.
