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
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.
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.
