Orchestral Tools - Berlin Free Orchestra

  • Ersteller emulator
  • Erstellt am
Ich habe im Laufe der Zeit einige Plugins gehabt, die auf ihre Weise unbrauchbar waren, bzw. mir wegen Latenzen oder Bedienung nicht gepasst haben. Die laufen eben nicht auf meinem Rechner, Ende Gelände. Ich vermisse nichts.
 
Du also offensichtlich genau das Sample "erwischt" was am schlechtesten geschnitten ist.
Aber wie kann etwas schlecht geschnitten sein? Ein Sampler sollte doch in der Lage sein Audio an der Wellenform richtig zu markieren und abzuspielen.
Eine Hüllkurve bei Samplern funktioniert sicher auch mit Abtastung des Samples über die gesamte Länge.
 
Ein Sampler sollte doch in der Lage sein Audio an der Wellenform richtig zu markieren und abzuspielen.
Würde er das automatisch/konsequent machen, wären die Laufzeitunterschiede zwischen verschiedenen Mikrofonpositionen futsch.
Solche Features gibt es zwar, aber bei Orchestersachen setzt man das besser nicht ein.
Eine Hüllkurve bei Samplern funktioniert sicher auch mit Abtastung des Samples über die gesamte Länge.
Wenn ein Sampler eine Hüllkurve(z.B. ADSR) hat, orientiert sich diese nur am Tastenanschlag. Genau wie bei jedem Synth.
 
Lade z.B. mal High Tom Ensemble und bounce das. Dann geh Du in den Sine-Mixer und mache nur das Close-Mikrofon an und bounce das.
Man sieht einen Zeitversatz. Aber bei dem Close-Sample ist die Verzögerung pi mal Daumen 0,5 bis 1 ms.

Oh stimmt, du hast recht. Danke für's Austesten.

Gut, da stellen sich mir dann aber diverse andere Fragen...

Du also offensichtlich genau das Sample "erwischt" was am schlechtesten geschnitten ist.

Leider nicht wirklich.

Ich habe auch diese "Crux" Bass Library installiert. Und da sind es dann bspw. beim J-bass 15ms.

Oder nehmen wir das Rhodes. Auch um die 15ms - wobei da tatsächlich eine Art "Pre-Ringing" vor dem ersten richtigen Attack sichtbar ist, was dann natürlich dafür spricht, dass es sich "nur" um eine Sample-Schneide-Geschichte handelt.

Beim Wurlitzer isses noch krasser:

OT_Wurli.png


Über 30ms bis zum ersten nennenswerten Attack (ok, bei etwas höheren Noten sind es "nur" 30ms...)?!?

Und so setzt sich das bei etlichen Patches fort - halt bei allen, die ich bisher unter den Fingern hatte. Ich halte die von dir entdeckten Toms fast schon für einen Zufallsfund.

Sorry, da kann man mir jetzt sonstwas erzählen, aber das ist einfach schlampige Sample-Nachbearbeitung. Ja, vielleicht ist das bei einigen Orchestersounds "authentisch" - aber wenn man es bei schnöden perkussiven Samples, die sich wirklich im Vollsuff sauber schneiden lassen, bereits komplett verreißt, dann wage ich, Zweifel anzumelden, dass es da mit der Sample-"Betreuung" so weit her ist. Ich habe die Vermutung, dass da einfach irgendwelche Makros bzw. Stapelbearbeitungen benutzt werden und man irgendwie mit "merkt wahrscheinlich sowieso niemand" oder "im klassischen Bereich wird ohnehin oft mit negativem Delay hingeschoben" durchzukommen versucht.

Ja, es gibt da sicherlich auch ein paar Patches, bei denen es OK bzw. in der Natur der Sache ist, dass es keine direkten Attacks gibt. Bei dem Berlin Orchestra kann das natürlich gut so sein, weil man da einfach die weiter weg stehenden Mic-Positionen benutzt hat, die dann (hier auch verständlicherweise) nicht eigens nochmal nachgeschnitten wurden.

Aber es zieht sich ja trotzdem wie ein roter Faden durch deren Libraries, "scharf" geschnittene Samples scheinen die Ausnahme zu sein. Und wenn man dann eben auch sowas wie E-Bässe oder E-Pianos (die ja gar nicht mal schlecht klingen) im Programm hat, die aber an sich wirklich beinahe komplett unspielbar sind, dann sind eben Zweifel hinsichtlich der Sorgfalt angebracht.
Und ein Support, der etwas von "mit 100-150ms kann man klarzukommen lernen" erzählt, ist dann auch nicht wirklich vertrauenserweckend.
Ich suche doch nicht fast jahrzehntelang nach den Interfaces mit den kleinsten Latenzen, nur um mir die Suppe dann durch schlecht (und zwar hier in vielen Fällen objektiv schlecht) geschnittene Samples versalzen zu lassen.

Und abgesehen von all dem ist der Sine Player ja dennoch kaputt. "Latency Buffer" macht, trotz anderslautender Erklärungen des Supports, exakt nichts und der Envelope Attack lässt sich, einmal angefasst, auch nicht mehr unter 5ms zurückdrehen (obwohl es in einigen vorgespeicherten Patches auch den Wert 1ms gibt).

Doof nur, dass ich jetzt nochmal mit dem Support rumschreiben muss. Und dass die sich dann vermutlich sagen "viel Wind um nix" (auch wenn es definitiv etliche Gründe für deutliche Nachbesserungen geben würde).

---

Achja, zu den Leuten, die "auf der richtigen" Plattform nicht gemerkt haben, dass es da einen Versatz gibt, naja... vielleicht sind Nutzer der "falschen" Plattform einfach timing-bewusster. Ätsch!
 
Ich bin halt ein Glückskind :)

Das war aber wirklich super, dass du den Patch gefunden hast. Durch den fast durchgehend gleich großen Versatz (der eben bei den Patches, die ich gestestet habe, eher höher als niedriger wurde), drängte sich eben der Verdacht auf, dass mit dem Player in punkto Latenz was nicht stimmt - tut's ja übrigens wirklich nicht, aber das hat dann nichts mit der Latenzgeschichte am Hut.

Ich find's übrigens nach wie vor erschreckend, dass die Samples so trimmen (oder eben womöglich auch nicht trimmen...). Weiß noch gar nicht, was ich dem Support schreiben soll. "Hey ok, euer Player macht zwar doch keinen Latenzstress, ist aber trotzdem halb-kaputt und außerdem könnt ihr nicht gescheit Samples schneiden!" - das kann's eher nicht sein, dann hetzen die mir 'nen Assassin auf den Hals.
 
Ich habe auch eine Rückmeldung vom OT Support.
Ich soll zwei Beispiele als Midi exportieren um den Output zu vergleichen.
1x für Logic, 1x für Cubase.
Damit soll wohl geprüft werden, ob die AU oder VST Version buggy ist.

Ich kann mir nicht vorstellen, das uns das weiterbringt.
Es ist ja eine gefühlte/gehörte Verzögerung beim Einspielen.
Ein Fall von "Audio-Esoterik"?
 
Ich habe auch eine Rückmeldung vom OT Support.
Ich soll zwei Beispiele als Midi exportieren um den Output zu vergleichen.
1x für Logic, 1x für Cubase.
Damit soll wohl geprüft werden, ob die AU oder VST Version buggy ist.

Ich kann mir nicht vorstellen, das uns das weiterbringt.
Es ist ja eine gefühlte/gehörte Verzögerung beim Einspielen.
Ein Fall von "Audio-Esoterik"?

Nee, ich denke, die Sache ist jetzt klar. Das liegt einfach an den Samples.
Macht es für mich nicht besser, ferner wundere ich mich, dass es noch niemand vorher wirklich bemerkt zu haben scheint, denn ich finde den Versatz bei einigen Patches wirklich ziemlich übel, so dass ich niemals auf den Gedanken käme die zu benutzen (ich mein, 30+ ms beim Wurlitzer?!?), aber so scheint's nunmal zu sein. Vielleicht nehmen die das ja wenigstens zum Anlass, die anderen Bugs anzuschauen, aber die werden gewiss nicht irgendwelche Bestandslibraries insofern überarbeiten, dass da alle Samples neu geschnitten werden.

Was allerdings möglich wäre (das werde ich denen auch schreiben), ist, dem Nutzer Zugriff auf den Samplestart zu erlauben. Dann sagste dem Wurli halt, das es alle Samples für den kompletten Patch bitte erst ab 30 Samples im Sample spielen soll. Den Parameter gibt's in deren Editoren bestimmt (kann ja eh jeder Sampler mittlerweile), muss nur für User sichtbar gemacht werden.
Damit könnten die mehrere Fliegen mit einer Klappe schlagen und die Nutzer würde es freuen.
 
Zuletzt bearbeitet:

Oft gelesene Themen

Zurück
Oben