Superior Drummer 2.0 Fragen über Fragen

Nutzt Du Toontrack-Solo? Dann prüfe doch einmal die folgenden Einstellungen:
- Hast Du unter <Options/Audio/Audio-Device> den Device-Type "Asio" gewählt?
- Hast Du unter <Options/Midi-Devices> ein Deltagerät angegeben?

Hast Du in der Systemsteuerung von Windoof unter Sounds die richtigen Geräte zugewiesen?

Mit so einem Tool wird allerdings nur die Latenz vom Audiointerface gemessen. Das TD-12 hinzugenommen, der MIDI-Weg, etc. wird man mit einer PC-Lösung ( aus meiner Erfahrung ) niemals unter 10ms Gesamtlatenz kommen. Um diese Latenz zu messen, muss man das Triggersignal vom Pad und das Audio-Ausgangssignal aufnehmen und dann den Versatz der beiden Signale im Audio-Editor checken. ASIO- bzw. Audiointerface-Latenzmessungen sind dagegen relativ belanglos, da sie nicht mal ansatzweise die Gesamtlatenz andeuten.

Hi Trommeltotti,

ja, da gebe ich Dir recht. Was mich am meisten schockiert ist die Erkenntnis, dass Übeltäter wie MIDI, Audiointerface-Latenz, etc. fast schon harmlos sind, wenn man sich mal anschaut, wo und wie ein rechnerbasiertes System viele Millisekunden an Latenz aufbaut, die theoretisch auf den ersten Blick gar nicht da sein dürften. Und wie lahm manche Triggermodule sind und Ewigkeiten brauchen, bis sie die MIDI-Note mal auf den Weg bringen.

Beispiel: Mein Audiointerface erzeugt 1,8ms Latenz bei der Audioausgabe. Eine MIDI-Note braucht ne gute Millisekunde zur reinen Übertragung (Datenmenge/Schnittstellengeschwindigkeit). Ein gutes und schnelles Triggerinterface braucht gute 2 Millisekunden (nicht die Roland-Module a la TD-12, die gleich mal 4ms benötigen). BFD erzeugt mit 32 Samples @44.1 nochmal 0,7ms. Die addierten Werte sollten also eine Gesamtlatenz von 6ms ermöglichen. Die Realität lag bei mir über 12ms. Der Laptop ist auch nicht der aller langsamste (Core2Duo,SSD,4GB DDR3 RAM). Wenn man dann noch ein durchschnittliches Triggermodul (Roland), geht unter 15ms gar nichts. Und Module wie das Alesis Trigger I/O sollen sich auch nicht mit Ruhm bekleckern, wenn es um Geschwindigkeit geht (hatte man doch erst gehofft, MIDI sei der Flaschenhals und Alesis habe das mit USB umgangen - Pustekuchen).

Ich habe vorerst daraus den Schluss gezogen, dass ein rechnerbasiertes System zurzeit für mich noch nicht in Frage kommt. Daher spiele ich nun ein DDrum3, welches mit Multisamples aus BFD gefüttert wird und ein DDrum4 für die Cymbals (und mehr). Da bleibe ich immer deutlich unter 3ms. Das DDrum4 liegt unter 2,5ms Gesamtlatenz und das DDrum3 werde ich noch messen. Aber es soll nicht langsamer gewesen sein.

10-15 Jahre später sind die E-Drum-Module am Markt langsamer, können keine eigenen Multisamples laden und die Rechnerlösungen befinden sich fern ab von vertretbaren Latenzwerten. Einziges aktuelles Modul, was da eine Ausnahme bilden könnte, ist das 2box. Aber das kommt aus anderen Gründen für mich (noch?) nicht in Frage, aber die Richtung ist grob schon mal die richtige aus meiner Sicht.

Es scheint mir so, als wenn man Drummer im E-Bereich sehr einfach zufriedenstellen kann, bzw. fast schon veräppeln kann. Wenn die Playability (Mesh Heads, halbwegs annehmbare Cymbal Pads) gegeben ist, kann ein Hersteller viele Tausend Euro für ein E-Kit verlangen, dass mit "durchschnittlichen" Latenzen, PCM-Wellentechnik aus den 80/90ern und sehr langsamer MIDI-Umsetzung daher kommt. Ich habe den Eindruck, dass Keyboarder da wesentlich kritischer und anspruchsvoller sind und sich nicht so leicht veräppeln lassen. Aber Drummern kann man viel (eigentlich wenig) für viel Geld andrehen. Das funktioniert nachweißlich. Von daher habe ich die Hoffnung aufgegeben, dass die Drummer-Kundschaft die Hersteller dazu nötigt, sich mal langsam Mühe zu geben. Im Gegenteil, Geschwindigkeitsrückschritte zur Technik von vor 20 Jahren werden ja auch in Kauf genommen ...

Ich bin aber sehr interessiert daran, ob und wie Du ein Rechnersystem mit geringen Latenzen hinbekommst. Evtl. ist es ja möglich, durch gezielte Komponentenauswahl, Konfiguration, Tunen, etc. dem Rechner die Bummelei auszutreiben, so dass sich die Gesamtlatenz auf Triggerverarbeitung,Audio-Interface, etc. reduziert. Wenn Du da erste Ergebnisse hast, würde mich das brennend interessieren. Ich habe nach den ersten Ergebnissen schnell aufgegeben und mich an DDrum Modulen erfreut.

Was mir noch zum Thema Triggerinterface einfällt: Ich kenne das Megadrummodul nicht. Aber wie ich verstanden habe, setzt es ebenfalls auf USB. Ich finde folgenden Ansatz interessant. Man nehme ein schnelles Audiointerface (z.B. RME) und benutzt die analogen Audioeingänge als Triggereingänge! Die Hersteller geben sich ja Mühe, schnelle Audiointerfaces mit minimalster Latenz zu bauen. Hersteller von Drummodulen schlampen hier ganz heftig. Vielleicht wäre es clever, auf ein schnelles Audiointerface als Triggereingänge am Rechner zu setzen. Somit sind die Signale direkt und schnell im Rechner. Dann müsste "nur" noch eine potente Software her, die das unterstützt und umsetzt. Hochwertige Audio-Wandler wären zwar für die Triggersignale ein paar Perlen vor die Säue, aber wenns damit schnell wird ....

Gruss.

Zitat von trommeltotti

Dazu sollte man aber ganz klar erklären, dass es zur Zeit gar kein kommerzielles Trigger-Interface am Markt gibt welches ohne wesentliche Verzögerungen beim umwandeln der Trigger-Signale in Midi-Steuerbefehle arbeiten kann. Denn auch die DDrum Module sind im Grunde genommen keine reinen Trigger-Interfaces und waren ja wohl auch seinerzeit gar nicht dafür konzipiert. (nebenbei sei auch bemerkt, dass auch diese Module nicht genügend Trigger-Eingänge für ein ausgewachsenes E-Setup zur Verfügung stellen)

Überhaupt kann man nach meiner Meinung an diesem Punkt sehr deutlich erkennen, wie unausgereift grundsätzlich diese simple Piezo Trigger-Technik ist! In den ROLAND Geräten ist die eingebaute deutliche Verzögerung von etwa 4ms nämlich sicherlich nicht ohne Grund erfolgt! Die Entwickler von ROLAND haben darin scheinbar die einzige Lösung gesehen, dass Schwingungsverhalten speziell von Meshpads und die damit verbundenen Problemen mit der Ausgabe von exakten Velocity-Werten bei einer schnellen Schlagabfolge auf dem Pad, als Midi-Steuerbefehle korrekt an dem Midi-Out Port zu senden. Mit diesem Problem haben alle Trigger Konverter zu kämpfen! Auch das nicht kommerzielle MD Modul.

Mit Deiner Vermutung bezüglich Roland und den notwendigen 4ms liegst Du vermutlich eher falsch. Die Scan-Zeit im Rolandmodul beträgt per default 2ms. Dieser Wert kommt nicht von ungefähr, sondern war schon vor 20 Jahren ein gängiger Wert, der erforderlich ist, bis der Peak des Triggersignals eintrifft. Erst dann wird der Dynamikwert bestimmt. Die 2ms werden übrigens auch im Simmons ADT immer von der Learn-Funktion automatisch ermittelt, die die Hüllkurve des Triggersignals abtastet und den Zeitpunkt des Peaks dabei ebenfalls ermittelt. Die 4ms des Rolandmoduls sind für mich eher ein Produkt aus geringer Rechenleistung des Prozessors und der Hardware-Architektur, wo eine CPU alles übernimmt. Wenn es Dich interessiert, kannst Du ja mal etwas im VDrum-Forum lesen, dort wurden Tests gemacht, die gezeigt haben, dass die Latenzwerte davon abhängig sind, ob und wie die internen Effekte genutzt werden. Hat also nichts damit zu tun, dass man solange brauchen würde, um ein Triggersignal anständig abzutasten.

Die DDrum Module sind ja der Beweis. Etwa 2ms werden benötigt, bis der Peak eintrifft. Und 0,4 ms später schmeißt das DDrum4 bereits das Audiosignal raus. Macht eine Gesamtlatenz von 2,4ms, wovon 2ms ja fürs Scannen des Triggers draufgeht. Egal ob Fell-Pad, Mesh Pad, Triggerpickup am A-Set, mit Händen gespielt, etc.

Klar waren die DDrum-Module keine reinen Triggermodule. Trotzdem kenne ich kein Triggerinterface, was die Qualitäten und die Geschwindigkeit bietet, wenn man das DDrum eben nur als reines Triggerinterface einsetzt, was man ja machen kann . Gute 2ms, mehr darf ein gescheites Interface nicht brauchen bis das Signal per MIDI oder USB zur Verfügung steht. Wenn DDrum das vor 15 Jahren konnte, dann würde ich heute nix kaufen, was zwei- bis dreimal so lange braucht.

Ja, das DDrum hat nur 10 Triggereingänge. Daher habe ich auch zwei Module. Ist mir lieber als ein Modul, was sich immer viel Zeit läßt beim Triggern

Zitat von trommeltotti

Also ich finde das ja bemerkenswert, kann mir aber überhaupt nicht vorstellen wie das funktionieren soll. Die einigermaßen gut vorhandene Lebendigkeit und Ausdrucksstärke der großen Drum Libraries wie bfd und SD beim Echtzeit-Triggering (jedenfalls im Vergleich zu herkömmlichen Modulsounds) funktioniert nur deswegen, weil hunderte bis gar tausende einzelne Samples - teils mit aufwändigen Algorithmen geschickt innerhalb einer Software Applikation gesteuert - in Echtzeit entsprechend "abgefeuert" werden. Dazu sind auch die DDrum Module gar nicht in der Lage, weil sie allein schon gar nicht die entsprechende Software laden können. Geschweige denn davon das sie genügend Festplatten Kapazitäten und Arbeitsspeicher aufweisen können. Ich weiß ja nicht wie das beim bfd ist. Aber die Toontrack Samples sind in einem speziellen Kompressionsverfahren auf der Disc abgelegt, damit diese innerhalb der Toontrack Software schneller in ein Setup "eingelesen" werden können. Wie kann man denn bei den DDrum Modulen bfd Samples einlesen? Das wäre mir neu! Ich lasse mich da aber gerne auch eines besseren belehren.

Es kommt drauf an. Die Software-Schmieden werben ja gerne mit den vielen vielen Gigabytes, die notwendig sind, damit es eine gut und realistisch klingende Library ist.
Wie kommen denn die vielen Gigabytes zustande?

Bei BFD kann man das ganz gut sehen, da die Samples nicht im proprietären Format abgelegt sind. Es handelt sich dabei um ganz normale wav files. Eine wav Datei hat allerdings 11 Kanäle. Das können nicht alle Editoren öffnen. Mit SoundForge geht es zum Beispiel. In der Regel ist der 11. Kanal das eigentliche dry signal (direkt abgenommen). Die anderen Kanäle sind zusätzliche Signalanteile von anderen Mikros (Raummikros, etc.). So kommt z.B. beim Snareschlag auch der Anteil, der über die anderen Mikros (Kick,Toms,OH,Room,etc.) geht, mit in das Sample. Das bedeutet, dass das eigentliche Dry-Sample nur 10% der Dateigröße ausmacht. Die Samples haben auch extrem lange Ausklangphasen. Zum Teil mit einigen Sekunden am Ende, die sich im Bereich -60dB abspielen! Bei der Installation der Sounds hat man ja auch noch die Wahl, wieviel Velocity-Layer man haben möchte. Wenn man dann einen Snaresound hat, der 1GB belegt, man das Dry-Signal rauszieht, ab -50dB mit z.B. 0,5s ausfadet, von 24 auf 16bit runterrechnet und sich sinnvolle Abstufungen bei den Multisamples raussucht, dann bleiben von dem Gigabyte schnell nur noch z.B. 10MB übrig!

Jetzt ist natürlich die Frage, worum es geht. Geht es

a) darum realistisch klingende Dry-Kits zu haben, die sich nicht nach E-Drums anhören, sondern nach Akustik-Set ohne Maschinengewähreffekt? Und man möchte eigene (Hall-)Effekte rauflegen?

Oder geht es zusätzlich

b) darum, dass man die volle Flexibilität beim Mix aus dem Hall des Originalaufnahmeraums hat und man auf Knopfdruck zwischen verschiedenen Raummikroentfernungen umschalten kann und den Signalanteil über die "Fremdmikros" stufenlos kontrollieren kann?

Mir geht es hier ganz klar um a) ! Das wollte ich nochmal erwähnen bevor man aneinander vorbei redet
Wenn es um b) geht, wird man mit einem DDrum sicher nicht glücklich und muss auf (latenzbehaftete) Software setzen.

Zu Deiner Frage: Die Multisamples lassen sich per MIDI (langsam) oder sehr flott per SCSI ins DDrum3 laden. Dort können sie dann den verschiedenen Velocity-Layern und den verschiedenen Zone-Layern (positional sensing) zugeordnet werden.

Nach viel rumprobieren bin ich für mich zu dem Schluss gekommen, dass absolut keine unzähligen Velocity-Multisamples erforderlich sind, um ein echt klingendes System zu haben. Wichtig ist vielmehr, dass intelligente Algorithmen dafür sorgen, wie die Samples abgespielt werden. Dazu gehört eine anständige Intervallkontrolle und Filter, die sich in Abhängigkeit von Dynamik-, Spielposition, etc. steuern lassen, eine sensible Dynamikumsetzung (die oft genannten 1000 Stufen des DDrums vs. 127 MIDI/Roland/PC/etc.). Und das ganze beherscht das DDrum sehr gut. Nachdem ich einige BFD Kits ins DDrum3 importiert hatte, viel Zeit mit der Erstellung und Verknüpfung der einzelnen Samples verbracht habe, hat es sehr viel mehr Spaß gemacht, die guten Sounds ohne fühlbare Verzögerung direkt anzuspielen. Rückschritte bei der Echtheit, Dynamik, etc. empfinde ich nicht. Auch wenns keine 100 Samples pro Trommel sind . Man hat halt nur nicht die ganzen Mix-Spielereien von BFD. Aber mit insgesamt 14 Einzelausgängen kann ich ausreichend differenziert mixen

Für mich bietet das DDrum zurzeit immer noch die beste Variante, gute Multisamples (z.B. BFD) mit robuster und flinker Triggertechnik verzögerungsfrei zu spielen. Und zwar so, dass es wirklich zuverlässig funktioniert. BFD verschluckt z.B. bei mir aufm PC gerne mal ein paar Schläge. Zwar selten, aber es kommt vor.

Zitat von trommeltotti

Dazu zähle ich:

• Eine völlige Neuentwicklung der Trigger-Technik die ohne diese simplen Piezo Abnehmer funktioniert! Diese muss genauso unkompliziert und Herstellerunabhängig auf jede erdenkliche Trommel zu montieren sein, wie ein normaler Fellwechsel auf einem A-Set. E-Drum Pads sind IMHO eigentlich überflüssig! (Ausnahme: Platzsparende FX-Pads wie etwa Tubes usw.)
• Ein neues Übertragungsprotokoll muss eingeführt werden.
• Auch bei den Cymbals muss gelten: Weck mit diesen simplen Piezos! Aus Lautstärke Gründen kann man aber hierbei wohl nicht auf eine Neukonstruktion von Pads verzichten. Diese sollten dann aber auch gleich entsprechendes Äußere aufweisen wie A-Cymbals.
• Leistungsfähige Hardware möglichst ohne bewegende Teile in einem Gerät , die neben den Computer Komponenten sowohl die Trigger-Technik enthält, wie auch die (Multi) Wandler-Technik.
• Ein neues kleines und schnelles Betriebssystem mit eigener Audio-Treiber Architektur muss her, welches auf nutzen von VST Instrumenten in Echtzeit abgestimmt und optimiert ist.
• Das Gehäuse sollte wahlweise als 19" Bauform für den Bühnenbetrieb und als Standalone Bauform für den Haus/Studio Gebrauch vorliegen.
• Entsprechende Drehpotis, Fader und Transporttaster usw. und gegebenenfalls ein Touchscreen Monitor zum steuern sämtlicher Funktionen muss vorhanden sein.

Simmons hat damals die FSR-Folie eingeführt. Vorteil gegenüber Piezos: Absolut kein Crosstalk, da direkt die Kraft des Anschlags abgenommen wurde. Damit sollte sich auch der Aufwand bei der Triggerauswertung reduzieren. Wer ein Simmons SDX hat, kann ja mal eine Latenzmessung durchführen. Würde mich brennend interessieren!
Die DrumKATs haben glaube ich auch mit FSR Folie gearbeitet. Aber heute will ja jeder Mesh-Heads. Und auch wenn man die 2ms bei der Triggerverarbeitung noch reduzieren kann, bringt das nicht viel, wenn der Weg bis zur Audioausgabe am Rechner dahinter nochmal über 10ms verschlingt

Ja, ein schlankes und dafür optimiertes Betriebssystem müsste her. Dass wiederum braucht natürlich auch eine passende Software. Das ganze müsste natürlich perfekt mit dafür selektierter PC-Hardware zusammenspielen und beides aufeinander abgestimmt sein. Dazu noch ein bühnentaugliches Gehäuse ..... . Und schon sind wir wieder weg vom PC und hin zu einer optimal abgestimmten Hardware-Lösung

Gruss.

Zitat

Was steht dem eigentlich entgegen diese FSR-Technik nicht auch an den Cymbal-Pads einzusetzen?

die FSR Folie ist z.B. teurer und bei weitem nicht so haltbar wie die klassische Piezzo Technologie. Kannst ja mal den Oli Rubow fragen wie oft er an seinem SPD-S die Folien wechseln muss Ich hatte selbst auch mal das SPD-20, das hatte aber zuletzt auch den ein oder anderen Dead Spot. Und zumindest bei den SDX Pads kann die Folie mit der Zeit oxidieren. Vielleicht hat sich das aber auch verbessert. Wen diese Technologie übrigens interessiert: http://www.simmonsmuseum.com/downloads/fsrguide.pdf
Diese Firma hat damals schon die SDX Folien hergestellt

Ich messe gerne mal bei Gelegenheit (wann das auch immer sein mag) die Latenz vom SDX

Hi Trommeltotti,

war ein paar Tage unterwegs, daher die späte Antwort. Freut mich, wenn Du mit meinem Beitrag etwas anfangen konntest. Die 2ms sind sicher kein in Beton gegossener Wert. Aber ein doch sehr gängiger Wert, der Hersteller- und Padtyp übergreifend meistens passt.

Mit dem Megadrummodul habe ich mich noch gar nicht beschäftigt, finde aber den DIY Ansatz gut und man kann hoffen, dass ein unter idealistischen Gesichtspunkten entstandenes Gerät nicht so viele Millisekunden vertrödelt, wie das aktuelle Module von großen Konzernen tun.

Ich kann auch verstehen, dass man den aktuellen Stand der (Rechner-)Technik nutzen möchte und berechtigterweise den Anspruch erhebt, diese Technik ohne große Nachteile (Latenz) nutzen zu können. Habe ja selbst BFD auf dem Rechner.

Es ist nicht so kompliziert, das DDrum3 mit Multisamples zu füttern und diese dann zu verknüpfen. Es ist halt nur zeitraubende Arbeit, weil man bestimmte Einstellungen x-mal für verschiedene Samples wiederholen muss. Hat halt ein bisschen was von Ameisen tätowieren
Und natürlich hat auch das DDrum3 seine klaren Grenzen, z.B. keine Cymbalpads. Daher beschränkt sich die Nutzung von externen Musltisamples auf die Trommeln. Für die Cymabls nehme ich immer noch das DDrum4. Das ist nicht verkehrt und die Werkssounds sind sehr gut, nix Maschinengewähr, etc., aber man hat halt nicht die Auswahl von externer Software.

Du würdest wohl drei Module benötigen, die 10 Triggereingänge pro Modul sind Monoeingänge (ausgenommen Hi-Hat DD4: Stereo) Zwar mit positional sensing (8 definierte Zonen pro Pad) und Pressure-Sensing (Steuerung vieler Parameter wie Tonhöhe, Decay, Attack, etc. durch Druck aufs Fell), aber eben keine seperaten unabhängigen Stereo-Trigger.

Für mich ist die Kombi immer noch die beste, um gute Multisamples naturgetreu zu spielen, ohne dabei Latenz- und Triggerproblemen ausgesetzt zu sein. Da gibt's, so traurig das ist, keine Alternative zu dem vor 17 Jahren(!) auf den Markt erschienenden Gerät!

FSR-Folie für die Beckenpads zu nehmen, ist eine gute Idee, da stimme ich Dir voll zu. Denn damit hätte man den typischen Zonenbrei eleminiert und keine Übersprechprobleme, die bei Beckenpads ja echt nerven können.

Ich bin recht froh, dass man zumindest bei BFD Zugriff auf die wav files hat. Bei Toontrack ja leider nicht, wie ich jetzt auch weiß. Weiß jemand, wie es da bei anderen Softwarepaketen aussieht?

Was mir bei den Soft-Drum-Dingern fehlt, sind die verschiedenen Zonen. Bei BFD sind es gerade mal zwei bei einigen Snares. Auf den Toms nur eine Zone. Da könnte ich mehr gebrauchen für die 8 Zonen des DDrums. Man kann beim DDrum3 auch ein Crossfade von zwei Samples über die 8 Zonen machen. Das werde ich mal bei einigen Sounds ersatzweise probieren, da leider nicht genug Zonensamples vorhanden sind.

Aber halte uns bitte auf dem Laufenden, wenn Du Fortschritte, bzw. neue Erkenntnisse bei Deinem PC-E-Drumprojekt hast. Interessiert mich, wie weit man dort bezüglich Latenz kommt.

Viele Grüsse

PS: Wolle: Ja, wäre schön, wenn Du das wirklich mal schaffen würdest, das SDX zu messen.

Hallo,

was ist den mit diesen Dingern:

http://www.aquariandrumheads.com/products/inhead

Vielleicht doch mal was neues in Richtung Triggertechnik ?

Man darf verspannt sein...bin auf jedenfall auf einen Test neugierig...

/Alex