dfh superior 2.0

Zitat

Ein Drummer hat (gewöhnlich) 2 Hände und 2 Füße und es kommt durchaus vor, das man alle 4 Extremitäten gleichzeitig benutzt.

Damit das zum Problem wird, müsste man aber wirklich mit einer Toleranz von 1ms "gleichzeitig" anschlagen. Das dürfte in den weitaus meisten Fällen nicht der Fall sein.

Zitat

Sollte auch noch ein Pedal des edrums permanent kontinuierliche Controllerdaten senden (das ddrum Hihat Pedal sendet z.b. kontinuierlich Midi Pressure Daten, um den Druck zu messen, wie fest man das Pedal runterdrückt, um den Sound der Hihat Becken zu modellieren)

Kontinuierlich heißt in diesem Zusammenhang, dass etwa alle 100ms ein entsprechendes MIDI-CC-Event ausgegeben wird. Wenn die Firmware ordentlich programmiert ist, hat dabei NoteOn Priorität, so dass auch hier kaum Probleme zu befürchten sind.

Insgesamt dürfte die MIDI-Latenz in den seltensten Fällen über den theoretischen Wert von etwa 1ms ansteigen. Dies setzt natürlich voraus, dass an dem MIDI-Interface nur das E-Drum hängt und nicht wie früher ein ganze Reihe von Synthies.

Wenn man jetzt weiter berücksichtigt, dass MIDI über USB heute nicht mehr ganz so ungewöhnlich ist (z.B. Yamaha DTXtreme 3), sollte sich die ganze MIDI-Latenzproblematik bald in Luft auflösen.

tonsel

Hio drumdidi,

wirklich tolle Auführung. 4 Sem Midi-Studium ist ganz schön heftig (oje). Bisschen mit Midi habe ich auch zu tun. Hier meine Berechnung zur Latenz, die mit deiner Ausführung soweit überein stimmt. Das es eine Latenz gibt ist doch vollkommen klar. Nur wie tonsel es beschreibt, muss ich ihm da Recht geben. Rein theoretisch kann man pro Takt und pro Instrument 3.840 Midi-Informationen senden. Das ist zwar sehr tehoretisch, es ist aber auch genauso theoretisch alles genau auf einen Tick spielen zu wollen. Das ist eher ein Zufall als gewollt. Daher kann ich mir nicht vorstellen, dass es aufgrund der dünnen Leitung einen Datenstau gibt.

Zitat

Ich spreche davon, das schnell gespielte Passagen im Drumtrack tatsächlich über Midi anders klingen als die Audiospur.
Das Midiprotokoll verurscaht eine Art Auto-Quantisierung der Datenmenge, weil es die Daten seriell hintereinander abarbeiten muss.
Dies führt zu Verschiebungen innerhalb des gespielten Materials.
Alles im ms Bereich aber hörbar!

Da bin ich mir nicht sicher ob es tatsächlich am Midi-Protokoll oder an den Trigger-Konvertern liegt, die ggf. die Signale nicht schnell genug in Midi-Signale verarbeiten/konvertieren können. Wenn das tatsächlich der Fall wäre, spielt es keine Rolle mit welchen Protokoll und Leitung die Daten gesendet/empfangen werden. Das Problem bestünde weiterhin.

Interessantes Thema und gute Besserung.

Gruß Ruby

Danke Ruby,

mein Kopf klart gerade etwas auf und da möchte ich doch gleich mal meinen Respekt für deine Ausführungen zum Thema Midi in dem von dir erstellten und gerade zitierten Beitrag ausdrücken.
Sehr schön dargestellt

Möglicherweise habt ihr ja auch recht. Ich bin halt dem Midiprotokoll gegenüber immer etwas skeptisch.

Ein zeitgemässeres, moderneres Protokoll, das vor allem auch das Editing deutlich vereinfachen könnte, wäre durchaus nicht verkehrt.
Wenn man mal bedenkt, was im Bereich Audio Editing in den letzten 15 Jahren passiert ist, wäre eine neue Midi-Implementierung nichts so ganz verkehrtes.
Midi ist ja in vieler Hinsicht recht kompliziert aufgebaut bzw. man muss so oft von hinten durch die Brust ins Auge.
Allein Midi Implementation Charts von Geräten sind einfach dermassen kryptisch und dieses Hexadezimalcodezeugs einfach absolut nicht mehr zeitgemäss.
Es gibt ja auch immer wieder Bestrebungen, das alte Protokoll zumindest zu überarbeiten.

Durch Midi over USB ist ja schon vieles besser geworden als noch zu früheren Zeiten.
Nur wie gesagt, stelle ich mir ein Editing von Edrumspuren, die massiv auf Nutzung von Controllerdaten setzen, ziemlich "unangenehm" vor.

Na ja, das soll ja jetzt auch nicht in eine endlose Grundsatzdiskussion über die Midiimplementation ausarten.

Das hat auch bei mir einiges erklärt, was ich bisher nicht wirklich begreifen konnte. Danke für die Ausführungen!

@trommeltotti

Zitat

Aber wenn ich das jetzt richtig verstehe müsste dann quasi bei einem Zusammenhang zwischen einem Note-On Befehl und z.B. einem Zone CC Controller Befehl für Positional Sensing ja unweigerlich eine Verzögerung entstehen da ja Midi Note-On Befehle Vorrang haben sollten aber eigentlich sollte ja der Midi Note-On Wert gleichzeitig mit der Anschlagposition übermittelt werden um ein sinniges Ergebnis erzielen zu können. Oder habe ich da jetzt einen Denkfehler mit eingebaut?

In diesem Fall dürfte zuerst das MIDI-CC und dann das NoteOn übertragen werden, da sonst die Sample-Auswahl bei einem Soft-Sampler nicht funktioniert. Damit ergibt sich ein reine MIDI-Datenübertragungszeit von ca. 2ms.

Zitat

Mein TD-8 erzeugt nachweislich eine Latenz von mindestens 3-5ms bevor die Midi Daten über dem Midi Port in mein RME Audio-Interface gelangen.

Bei dieser Latenz muss auch die ScanTime (Triggerparameter) berücksichtigt werden, die meist 2ms beträgt. Dazu noch die AD-Wandlung mit 0,x ms. Damit ist eine Verzögerung von 3-5ms durchaus plausibel. Ich frage mich an dieser Stelle allerdings, wie man diese Verzögerung mit DIY-Mitteln misst.

Zitat

Noch mieser sind die Werte von meinem Alesis Trigger I/O Interface, welches so in etwa 6-8ms Latenzen erzeugt.

Eine ähnliche Erfahrung habe ich beim Vergleich PCI-MIDI-Interface zu USB-MIDI-Interface gemacht. Hier ist USB auch immer etwa 2ms schlechter. Dieses Problem sollte eigentlich durch bessere Treiber behebbar sein.

tonsel

Hi,

Zitat von drumdidi

mein Kopf klart gerade etwas auf und da möchte ich doch gleich mal meinen Respekt für deine Ausführungen zum Thema Midi in dem von dir erstellten und gerade zitierten Beitrag ausdrücken.
Sehr schön dargestellt

Danke.

Zitat von drumdidi

Ein zeitgemässeres, moderneres Protokoll, das vor allem auch das Editing deutlich vereinfachen könnte, wäre durchaus nicht verkehrt.
Wenn man mal bedenkt, was im Bereich Audio Editing in den letzten 15 Jahren passiert ist, wäre eine neue Midi-Implementierung nichts so ganz verkehrtes.
Midi ist ja in vieler Hinsicht recht kompliziert aufgebaut bzw. man muss so oft von hinten durch die Brust ins Auge.
Allein Midi Implementation Charts von Geräten sind einfach dermassen kryptisch und dieses Hexadezimalcodezeugs einfach absolut nicht mehr zeitgemäss.
Es gibt ja auch immer wieder Bestrebungen, das alte Protokoll zumindest zu überarbeiten.

Ich will mal so sagen, versuche mal das TCP/IP - Protokoll mit all seinen Layern zu verstehen, daran saß ich einige Semester dran um ein Netzwerk aufzubauen. Jeder würde daran verzweifeln, wenn es keine vernüftige Treiber dazu gäbe. Und genau hier ist das grundlegende Problem. Keiner weiß wie das TCP-Protokoll funktioniert, aber es funktioniert einfach per Plug&Play. Aber nicht weil das Protokoll so dolle ist, Nein, weil es Treiber und Software gibt, wo ein User auf einfachste Weise seine Konfigurationen durchführen kann. Vielleicht kann sich noch einer daran erinnern, Soundkarten und Netzwerkarte zu jumpern und die dazugehörenden autoexec.bat und config.sys immer und immer wieder neu zu konfigurieren... Oje, waren das Zeiten, aber auch schöne! Und an diesem Level steht auch das Midi-Protokoll und deren unterstützende Software als Frontend.

Alle Klangerzeuger heutzutage konzentrieren sich auf das Erzeugen von Klänge und schicken halt ein Midi-Signal, alle SW-Sequencer machen alles bunter aber nicht unbedingt einfacher. "Steuern soll jemand anderes" Für das TD-10 gab es schon vor 10 Jahren Software (Nein, nicht umsonst) wo ich die komplette Modellierung am PC per Midi in Echtzeit vornehmen zu können. Da sieht man das es geht und wie einfach das für einen User war....

Ich will damit sagen, ein Protokoll egal welches kann noch so alt sein, wenn es nur eine optimiertere userfreundliche Software gäbe. Und man müsste sich nicht mit grundlegenden Themen rumschlagen. Ist schon schlimm genug, wenn man im Hex-Mod konfigurieren muss. (brauch kein Mensch. Es programmiert ja auch keiner mit einer Maschinensprache...) Aber glaub mir es gibt auf einigen Unix-Servern Editoren, die sind über 30 Jahre alt, da schafft man es nur mit Aufwand eine Zeile zwischen den Code einzufügen und einige Leute behaupten heute noch das sei der beste Editor der Welt. :biggrin: Und so ist es sicherlich auch in der Midi-Welt.....

EDITH

Zitat

Hier liegt nämlich IMHO noch der Hund begraben: Ein Trigger-Interface muss halt erst einmal die Triggersignale digitalisieren und in Midi Befehle bzw. CC Controller Daten umwandeln. In diesem Bereich sehe ich noch erhebliches Optimierungspotential.

So ist es... Wobei ich davon überhaupt keine Ahnung habe, wo die physikalischen Grenzen liegen.

Gruß Ruby

Zitat von Ruby

Aber glaub mir es gibt auf einigen Unix-Servern Editoren, die sind über 30 Jahre alt, da schafft man es nur mit Aufwand eine Zeile zwischen den Code einzufügen

Ähm... du setzt den Cursor ans Ende der Zeile und drückst Enter? Oh, ja, die Zeile wird natürlich nicht für dich getippt. Zumindest nicht ohne weiteres (dass vi erweiterbar ist wie kein anderer, weißt du aber, oder?) - dein Editor entwickelt deinen Code für dich?

Zitat

und einige Leute behaupten heute noch das sei der beste Editor der Welt. :biggrin:

Das behaupten die, weil es stimmt. Wer vi beherrscht, für den ist das, was du behauptest dass es Aufwand sei, überhaupt kein Aufwand. Und eine Menge Dinge, die mit "normalen" Editoren aufwändig sind, sind mit vi auch kein Aufwand. Es ist Aufwand, vi bedienen zu lernen, ja. Lernen ist generell mit Aufwand verbunden.

*klugscheiß*

Death to Emacs! Vi forevah!

Zitat von userfriendly

Das behaupten die, weil es stimmt. Wer vi beherrscht, für den ist das, was du behauptest dass es Aufwand sei, überhaupt kein Aufwand. Und eine Menge Dinge, die mit "normalen" Editoren aufwändig sind, sind mit vi auch kein Aufwand. Es ist Aufwand, vi bedienen zu lernen, ja. Lernen ist generell mit Aufwand verbunden.

Da haben wir schon einen

Wie lernen? Anstöpseln und Loslegen! Das ist die Welt in der wir heute leben! Wenn es mit dem anstöpseln und loslegen nicht klappt ist alles Sch... :-))

Gruß Ruby

Zitat von Ruby

Da haben wir schon einen

Wie lernen? Anstöpseln und Loslegen! Das ist die Welt in der wir heute leben! Wenn es mit dem anstöpseln und loslegen nicht klappt ist alles Sch... :-))

Gruß Ruby

Hmm. Jetzt wo du es sagst... Hätte ich doch mal mit der Einstellung mein Studium begonnen. Wäre viel schneller fertig geworden.

das "Making Of" sollte eigentlich für alle Zeiten alle Mikrofonierungs-, Stimm- und Soundfragen beantworten. Wenn man sich das Double Bassdrum Gedaddel mal wegdenkt sind das eigentlich ganz gute Allround Sounds auch für für Nicht Metal

Ich hab jetzt auch Superior Drummer und nutze es mit meinem (genialen) A-Umbauset. Die Klänge sind einfach fantastisch, das ist kein Vergleich zu den Rolandsounds, absolut nicht. Dass sich die Becken nicht chocken lassen ist allerdings definitiv mehr als nur ein Wehrmutstropfen, so gut die Sounds auch sind, da fehlt dann eine, wie ich finde, recht entscheidende Ecke Realismus. Woran liegt das eigentlich, dass es nicht geht? Die Info dass der Kontakt berührt wurde lässt sich wohl nicht per MIDI übermitteln?

Du kannst die Becken choken. Ist ein kleiner Workaround. mit der ADS-Kurve. Such mal im Toontrack-Support-Forum oder über google.
Ich bin mir nicht ganz sicher, ob ich das jetzt aus dem Kopf und ohne das Programm offen zu haben hinbekommen, aber es geht etwa so:
Gewünschtes Becken rechtsklicken zum Anwählen. Im Pulldownmenü rechts entsprechend Rand- oder Kuppensound auswählen. Checkbox "edit articulation only" anwählen. ADS-Kurven-Checkbox anwählen. Aftertouch anwählen und Sustainkurve auf sehr kurzen Wert einstellen.

Sorry - das klingt ohne Programmreferenz etwas komplizierter, als es tatsächlich ist...

Mit Werten um 120ms herum läßt sich das Choken recht realistisch darstellen.

Edith meint, dass Du auf die "Envelope"-LED klicken musst, und wie oben geschrieben "Aftertouch" wählen. Dann rechts neben Release den unteren rechten Punkt der Kurve mit gedrückter linker Maustaste nach links schieben.

Hallo zusammen,

mit einem Bekannten möchte ich am Nachmittag DFH Superior auf seinem Mac mit einem E-Drum (glaube TD-8) ausprobieren. Nun habe ich eine Frage zur Reihenfolge der Installation, wenn DFH als Standalone Version betrieben werden soll. In der README Datei steht nämlich folgendes (nur Auszüge):

Zitat

To install, navigate to the /Install folder relevant to your platform (Mac or PC) and double click on the Superior Drummer Installer located in this folder and follow the instructions.
[...]
Once the Software Installer has completed successfully, the Installer will automatically launch the installation of the Superior Drummer 2.0 Sound Library.
[...]
Superior Drummer 2.0 ca also be use in stand alone mode, for example to trigger it from an electronic drumkit. Please make sure you run the Toontrack solo Installer located in the same folder as the main installer (/install/MAC/ or /install/PC) if you wish to use the product in this fashion.

Wir wollen das Modul ja zum Triggern verwenden. Müssen wir dann also nur mit der Installation von Toontrack Solo beginnen und hoffen, dass danach die Sound Library installiert wird und den Superior Drummer Installer ignorieren? So wäre ich jetzt vorgegangen, da ja kein externer Sequenzer verwendet werden soll. Mein Bekannter hat da sicher auch einen aber die Hürde soll am Anfang klein gehalten werden. Will ja erst einmal einen Eindruck vom sound der Library bekommen.

Vielen Dank im Voraus.

Simon

Auf gar keinen Fall. ERST Superior installieren - dann Toontrack Solo. Andersherum schlägt fehl, da Solo die benötigten Daten nicht findet.

Zitat von Catzzzpaws

Auf gar keinen Fall. ERST Superior installieren - dann Toontrack Solo. Andersherum schlägt fehl, da Solo die benötigten Daten nicht findet.

das haben wir so gemacht. Anschließend installierten wir die Treiber für sein USB MIDI-Interface M-Audio Midisport 4x4 und starteten den Toontrack Solo. In den MIDI-Einstellungen wählten wir das Interface und stellten bei Controller auf E-Drum um, wobei wir auch die anderen Möglichkeiten versuchten. Wenn man am TD-6 spielt, ist in der Solo Oberfläche nichts zu sehen oder zu hören. Das Interface blinkt aber und signalisiert eine Verbindung. Wie müssen wir vorgehen, um das Modul zum Antriggern von Toontrack zu bewegen?

Für Hilfe wäre ich dankbar, da ich mir gerne einen Eindruck von Superior verschaffen würde, bevor ich meine Anschaffungsplanungen noch einmal angehe und konkretisiere.

Gruß
Simon

In toontrack solo muss der richtige midi-input gewählt sein. Dann natürlich der richtige audio-output. Ein superior2 set muss natürlich auch geladen werden. Dann sollte das eigentlich funktionieren.

Hm, ich würde auch liebend gern die TD-12 Samples zum "live" spielen durch Superior ersetzen, aber irgendwie ist das alles relativ kompliziert für einen Ahnungslosen wie mich. Ich hab mich zwar schon ein wenig eingelesen, aber so wirklich kapiert hab ich nicht was ich eigentlich dafür brauche. Immerhin hab ichs schon geschafft mir ein paar bessere Kits per Midi mit nem Cakewalk UM-1G Interface auf das Modul zu laden, yeah!

Im Moment hab ich nen Core 2 Duo 6600 mit 2 GB Ram auf einem ASUS P5W-DH Deluxe Mainboard mit stinknormaler Realtek onboard Soundkarte, komme ich mit dieser Ausstattung hin um einigermaßen ohne Verzögerung spielen zu können? Ich les hier immer von Latenz und ASIO etc. Ich habe mir mal dieses ASIO 4 all geladen, aber wirklich erkannt wird das von der Realtek HD Software/Treiber nicht. Man braucht also zwingend eine bessere Soundkarte um da live (fast) ohne Verzögerung spielen zu können...das Midi Interface "reicht" nicht? Was genau ist/macht ASIO eigentlich?

Ich will mir eben nicht für über 200 Euro Superior(+Toontrack Solo) kaufen um dann festzustellen, dass es nicht funktioniert... und mit der Rückgabe von benutzter Software ist das ja so eine Sache.