E-Drum Technik-Thread (für Elektrotechnik- und Informatik-Interessierte)

Hi,

Erst mal Respekt und vielen Dank für all die verschiedenen Messungen, ich konnte deine Edits sogar quasi live verfolgen :).

Als du das mit dem Vergleich: Pad an Modul geschlossen und Pad direkt an den Oszi, gemacht hast, hab ich auch erst mal direkt an ein Filternetzwerk gedacht... Ich hab kurz darauf einfach mal mein TD8 aufgeschraubt(geht recht einfach, sind 6 Kreuzschlitzschrauben, dann ist man an den interessanten Teilen).

Leider hab ich kurz darauf festgestellt, dass der meiste Teil ASICs von Roland sind(bei den Modulpreisen von Roland verständlich )
Kurze Liste der interessanten ICs bzw. der Eigenschaften(mit IC-Namen kann hier wohl kaum jemand was anfangen):

1x 64 Mbit Mask Rom (Ich denke hier sind sämtliche Daten wie Sounds/Playalongs etc. drauf, halt Sachen die einmal geschrieben werden müssen, und dann nur noch gelesen werden)
1x 16Mbit Bootblock Flash (für den Bootloader und Userdaten vermutlich)
2x 70ns 1Mbit SRAM(8x128k)
1x 4Mbit DRAM(16x256k)
2x d63200 (DA-Wandler wahrscheinlich für analogen Audio-Output verantwortlich)
1x PCM3001E(auch DA-Wandler)
2x74HC14(Hex Schmitt-Trigger Inverter)
ein paar(Anzahl vergessen aufzuschreiben, waren glaub ich mehr als 4): 4053BF:

Zitat

The CD4053B is a triple 2-Channel multiplexer having three separate digital control inputs, A, B, and C, and an inhibit input. Each control input selects one of a pair of channels which are connected in a single-pole, double-throw configuration.

Dann 4 Roland ASICs, die selbst Google nicht kannte...

Sonst gibt es noch jede Menge OPAmps, und restliches Hühnerfutter, jedenfalls nichts näher Interessantes (Oder anders gesagt ich hatte keine Lust noch mehr ins Detail zu gehen ).

Ach ja und fast vergessen, warum ich das Ganze gemacht habe:

Leider konnte ich das Signal nicht weiter verfolgen, da ich dann das innere Board vom Gehäuse hätte trennen müssen, wo sämtliche Buttons befestigt waren-> war mir auch zuviel Arbeit...

Aber ich kann mir denken wie es weitergeht:

Das Signal kommt in einen der zahlreichen Opamps, und macht es für die Multiplexer gerecht, an diese wird es dann weitergegeben, und kommt per (vermutlich integriertem) AD Wandler in eines der Roland ASIC, welches für die Signalauswertung verantwortlich ist. (Der Rest ist m.E. uninteressant, da ja sowieso nur Soundmatsch aus den Modulen kommt :D.)

Sorry, dass ich keine genauen Werte habe dafür, mein Messgerät ist leider noch ein paar hundert Kilometer von hier entfernt....
Aber ich glaub sowieso, dass man ohne auslöten der Teile nicht die genauen Werte messen kann(zuviel Einfluss anderer Teile), und bei SMT bin ich da lieber vorsichtig...

Gruß
Philipp

Zitat

Na, wenn das jetzt eine indirekte Aufforderung war, mal das TD-12 aufzuschrauben, dann hat's funktioniert.

Wars nicht, aber was rausgekommen ist trotzdem genial, und übertrumpft meine Analyse bezüglich Piezosignalverwertung um Weiten .

Man sieht, dass es ähnlich anfängt bei dem Modul, Das Schaltbild von mir kann man übernehmen, also schätze ich mal, dass der Aufbau der Modul-Triggerauswertung ähnlich, wenn nicht sogar gleich sein wird.

Ich hab mal nach dem Apell(

Zitat

Wenn jemand Spaß dran hat, das mal zu genauer zu analysieren, nur zu!

versucht den Rest auf eine Schaltplanskizze zu übertragen, bin dann aber an den FETs gescheitert (N-Kanal?, P-Kanal?, Pinbelegung?). Naja Reverse-engineering wäre sowieso noch einiges mehr gewesen(induktionswerte, Kapazitäten etc.).
Letztendlich zählt ja die Erkenntis vom Ergebnis, und die kommt dank deinen Messungen recht gut rüber.

Jedenfalls sehe ich mit dem Signal "kein" Problem mehr bei der Positional Sensing, und Dynamikauswertung.
Dynamik wird einfach mit der maximalen Spannung des Signals innerhalb der Scantime ausgewertet.
Positional Sensing misst dann einfach die Zeit zwischen den ankommenden Peaks.
In den Roland Patenten wird das ja auch mehr oder weniger beschrieben(Bild mal von unseren englischen Kollegen geklaut, da es ohne Registrierung nicht ansehbar ist):

Viel DSP ist da dann natürlich nicht mehr nötig...

Gruß
Philipp

Zitat von buff

Im Prinzip würde ich das Ganze als eine Art Gleichrichterschaltung bezeichnen, mit evtl. ganz bestimmten Eigenschaften die einem so nicht offensichtlich sind.

Oder die sind ganz einfach zum Schutz vom IC, sei es wegen ESD, Spitzen vom Piezo oder Spitzen beim Einstecken.

Zitat von buff

Mit Gleichrichterschaltung meinte ich halt die gesamte Schaltung an den (normalen) Eingängen, das endgültige Signal könnte man ja mehr oder weniger als gleichgerichtetes und ansatzweise geglättetes Eingangssignal beschreiben.

Ah, die Gesamtschaltung.

Gleichrichtung sehe ich aber da nicht, das Signal geht schließlich auch unter den Offset/virtuellen Ground. Ich würde sagen das Signal wird einfach soweit angehoben dass keine Pegel unter 0V mehr auftreten, damit der nachfolgende Controller/AD-Wandler keine negative Versorgungsspannung braucht.

Zitat von buff

Zugegeben wurde es jetzt aber auch etwas unübersichtlich mit den ganzen Schaltungen.

Dann könnten die Dioden in dem Fall ja doch für die Opampschaltung sein um einen Vollwellengleichrichter zu erhalten.

Hi buff,

jetzt bin ich längere Zeit irgendwie nicht dazu gekommen zu schreiben:
Ich finde es klasse wie viel Engagement du da rein steckst!
Du baust uns bald noch den Triggerteil eines Rolandmoduls nach... .

Zitat

C77 macht ihn zusätzlich zum Tiefpass, und die D7-Dioden sollten ihn darüber hinaus zum Logarithmierer machen.

Genau das vermute ich auch. Das ist mir schon bei dem Snare-Signal aufgefallen, jetzt hast du es ja quasi schaltungstechnisch bewiesen.

Ein Logarithmierer ist auch definitiv sinnvoll, dann geht man den Problemen aus dem Weg, die man derzeit teilweise beim Megadrum Modul hat:
Man muss je nach Stärke des Eingangssignals ein Potentiometer davor setzen, um halbwegs "vernünftige" Dynamikerkennung zu erhalten.

Zitat

Das geht dann zwar auf Kosten der Auflösung bei stärkeren Signalen

Ich glaub das ist noch nicht mal so schlimm, wenn man die (logarithmische) Kurve relativ gut kennt.
Denn wenn der AD-Wandler halbwegs vernünftig auflöst, kann man das Ganze sehr gut Software-technisch ausgleichen.
Man hat einfach ein Array mit vielen Werten der Kurve, und wendet dieses dann einfach auf das Eingangssignal an, dann hat man theoretisch wieder das Ausgangsignal, nur digital(und damit weniger Probleme).
(ist jetzt eher der informatische Teil )

Kann es sein, dass du bei dieser Messung ausversehen vielleicht die falsche Referenzspannung genommen hast? Mich wundert es irgendwie ein wenig, dass es anscheinend eine Grundspannung gibt.

Zitat von buff

Signale (türkis=Signal vom Pad, gelb=Ausgang auf dem 1. und 2. Bild):

Übrigens, um vielleicht auch noch mal was "beizutragen":
Ich plane, und versuche derzeit/demnächst, mit "jack audio"(nette API) unter Linux einen DSP-Trigger zu programmieren, um da vielleicht ein paar Erkenntisse der Triggersignalverarbeitung zu sammeln.
Die Soundkarte löst ja mehr als ausreichend auf(24bit, bei 192khz Samplerate).

Latenzmäßig sollte auch alles sehr gut gehen, da ich unter Linux unter bestimmten Vorraussetzungen, Buffergrößen von 16 frames/Samples erreichen kann, und das bei einer Samplerate von 48k!
Linuxsampler, hatte ich dadurch teilweise mit einer Gesamtlatenz von 5ms(!) am Laufen gehabt (ca. 1.6ms Audiolatenz, gemessen).
Mit einem aufs System optimiertem Realtime Kernel, ist schon einiges möglich was Low-Latency angeht :).

Leider läuft Superior Drummer nur mit 64 Samples(auch unter Linux). Ist halt für Windows, und nutzt deshalb nicht die möglichen performanten Features unter Linux, bzw. muss über Umwege an Jack geleitet werden(wineasio).

Naja ich schweife ab...

Geplant ist es, dass Ganze nachher auf ein "Raspberry Pi" ähnliches device zu bringen(wenn nicht sogar dieses). Dazu möchte ich mir vielleicht demnächst ein odroid x2 besorgen, was mehr als potent, für solche Sachen geeignet seien sollte.

Aber alles noch etwas fernere Zukunft ;).

Gruß
Philipp

So, noch was neues aus der Linux/Informatik-Szene:

Hier ist ein relativ frisches neues Sampler-Programm, explizit für Linux und ALSA.
Das Ganze ist ein Standalone-Programm, welches das Midi-Gerät über den Raw-Modus öffnet, und über eine direkte Verbindung zum ALSA Treiber, die Samples ausgibt.
Derzeit gibt es leider erst das Salamander Drum-kit dafür. Aber der Entwickler(jeffg) plant ein Tool dafür zu veröffentlichen, mit welchem man eigene Samples dort einbinden kann.

So nun zu dem Grund warum ich das hier veröffentliche: Ich habe sagenhafte 1 Sample/Frames-size bei 96khz Samplerate hinbekommen, mit fast keinen Störgeräuschen, das sind theoretische 0.01ms Audiolatenz!(natürlich mit RT-Kernel)

Ich war erst mal fassungslos, als ich das erreicht habe(wie man auch an meinem Post dort merkt ). Aber ein paar Messungen haben das Ganze mehr oder weniger bestätigt: 3.3ms Gesamt-Latenz!
Das will mir mal einer nachmachen .

Tja es hängt eben doch alles an der Software...
Von dem Gedanken ein RME zu holen bin ich auf jedenfall erst mal abgebracht worden .

Also an die Linuxer hier: Support für das Programm ist angesagt ;).
Vielleicht will sich ja mal einer erbarmen, sein akkustisches Set in Samples aufzunehmen(ich weiß ist 'ne Heidenarbeit)
Ich mach das vielleicht mal in den Semesterferien, falls ich irgendwie an halbwegs vernünftige Mikros komme.

Gruß
Philipp

Zitat von trommeltotti

Also: Für mich wird Linux erst dann interessant, wenn es das VST-Protokoll vollständig unterstützen sollte und damit in der Lage wäre, gängige VST PlugIns zu laden.

Leider glaub ich wird da nicht so schnell was passieren, da die Hersteller der VSTs selber auf die Idee kommen müßten.
VST ist leider vor allem Windows vorbehalten(sieht man ja schon an der Endung der VSTs ".dll")

Zitat von trommeltotti

Die intelligente Steuerung der Samples in Echtzeit macht die Würze. Von den immensen virtuellen Mixer Möglichkeiten der ausgewachsenen VST Drum-PlugIns einmal ganz abgesehen.

Ich behaupte mal, dass da nicht soviel intelligente Steuerung stattfindet.
Das womit die kommerziellen Sampler punkten können ist vor allem die Sample-Menge, bei gleichzeitig überragender Qualität.
Das in Software zusammenzumischen ist nicht die große Arbeit, die findet nämlich m.E. eher im Studio statt, bzw. nachher beim Sample zurechtschneiden/rauspicken...
Auch Sachen wie Bleeding, Kompressor, Eq, ist alles keine Hexenarbeit in Software...

Klar wenn man noch mehr erreichen möchte, als die Möglichkeiten, die z.B. Superior Drummer derzeit bietet(ich spreche da vor allem die Hihat an), kann das sehr wohl, sehr schnell ziemlich komplex werden.
Alleine die verschiedenen Stufen der Hihat so überzublenden, dass man da nichts mehr hört, stell ich mir sehr schwer vor...

Zitat

Bei diesen sensationellen Werten würde ich glatt danach rufen wollen, dass große etablierte Software Hersteller nunmehr für das ALSA Protokoll eine größere Gewichtung zukommen lassen sollten.

Das liegt in erster Linie glaub ich nicht mal direkt an ALSA, sondern eher an der Echtzeitfähigkeit des Kernels, welcher gleichzeitig so gut mit der Soundkarte zusammenarbeitet. Die Treiber sind ja schon im Kernel eingebaut, welchen ich genau auf mein System optimiert kompiliert habe...

Und natürlich, die Software, welche die Sounds reichen muss. Da ist das Programm von jeffg schon ein sehr gutes Beispiel für.
Aber ich muss sagen ich war selbst sehr überrascht, was da möglich ist(der Entwickler im Übrigen auch).

Zitat von buff

Die Messung stimmt schon so. Bei der Snare-Schaltung werden die negativen Wellen ja nicht "hochgeklappt" wie in der anderen Schaltung, sondern bleiben so. Der A/D-Wandler vom TD-12 kann aber offenbar keine negativen Spannungen messen, also wird der Nullpunkt einfach auf ca. 1.65V hoch geschoben (das passiert in der zweiten Hälfte der Snare-Schaltung ab dem "Continue", simulier den Teil vielleicht einfach mal, wenn es nicht klar ist). So passt dann ein komplettes Wechselsignal in den Bereich von 0-3,3V, den der Wandler digitalisieren kann.

Alles klar das ergibt Sinn.

Zitat von buff

...(was ich noch schlimmer finde) weil jemand sein Wissen nicht weitergeben möchte....

Das Problem was ich dabei sehe, ist, je mehr wir in den technischen Bereich gehen, desto leichter/größer ist die potenzielle Kopiermöglichkeit, daher, kann dann einfach jemand mit den Erkenntnissen eine neue "Geschäftsdidee" darauf gründen. Das klingt jetzt zwar was hochgesetzt, aber es gibt nicht umsonst Patente, die eben sowas verhindern sollen...
Ich bin generell auch eher für offen verfügbares Wissen, nur ist das Ganze in der heutigen Zeit ein wertvolles Gut, das man in bestimmten Fällen schützen muss...

Gerade in diesem Bereich, sehe ich eine Marktlücke, die wenn man es geschickt umsetzt selbst Roland gefährlich werden könnte(man muss schneller als Roland handeln).

Zitat von buff

Linux mit Realtime-Kernel hat auf jeden Fall viel Potential, ich hatte selber auch mal vor einiger Zeit damit rumprobiert und kam bei Tests auf einem Atom-Board (lüfterlos) mit Onboard-Soundkarte auf (nachgemessene) 1,3ms Latenz zwischen Eingang des Midi-Signals und der Soundausgabe.

Sehr schön noch ein Linuxer, die Welt ist ja doch nicht so klein . Schön was du schon mit dem Atom-Board erreicht hast, da werde ich ja noch zuversichtlicher mit meinem Vorhaben das mal mit einem Odroid X2 zu probieren.
Da man ja auch noch einen Quadcore bei dem Odroid x2 hat, und dadurch theoretisch einen kompletten Kern für die Soundausgabe nutzen kann, sollte latenztechnisch vielleicht noch mehr drinnen sein.

Aber ich glaube das, dass Programm von jeffg, welches ich heute getestet habe schon mehr als ausreicht(2%CPU Last, bei 1 Sample Framesize und 96khz, ich kanns immer noch nicht ganz glauben...).
Vielleicht willst du es mal damit versuchen. Das Salamander Kit klingt schon recht ordentlich, Qualität vergleichbar mit EzDrummer, nur sehr trockener Sound(die Snare ist der Knüller ).
Das Ziel was jeffg erreichen möchte, ist ein einfach bedienbarer extrem schneller/effizienter/ressourcensparender Echtzeit-Drumsampler, also eigentlich genau das was wir unter anderem suchen.

Mein Traum/Ziel ist es ja irgendwie, etwas in Richtung Raspberry Pi/Odroid X2 zum Laufen zu bringen, welches mit einer ADC(Multiplexer)-Leiste die Triggereingänge in entsprechende Informationen verarbeitet, diese dann in Echtzeit entsprechende Samples aus dem RAM picken, und ausgeben. Dazu noch einfach bedienbare Möglichkeiten wie Bleeding oder Effekte(EQ/Kompressor), ähnlich wie in Superior Drummer.
Und fertig ist der Roland-E-Drum-Modul-Killer.
Hat jemand Lust in dem Bereich Karriere zu machen?

Wie schon oben mal angedeutet, versuche ich mal in den Semesterferien mein Set mit Samples abzunehmen, selbst wenn ich dabei lange nicht auf die Qualität des Superior Drummer komme, ist das Ganze wie du ja schon meintest, ein guter Erkentnisgewinn. Auch auf das Recording an sich bezogen, da ich, wie ich zugeben muss noch keine Erfahrung in dem Bereich habe...
Außerdem: Wer kann schon auf seinem E-drum Set sein eigenes akkustisches Set spielen .

Gruß
Philipp

Hi Philipp,

wenn Du nur Samples für den Eigengebrauch suchst kannst Du Dir auch 2Box-Sounds runter laden. Die sind kostenlos erhältlich aber halt nicht frei im Sinne von freier Software. Das verwendete DSND-Format ist im Prinzip eine WAV-Datei. Man kann sie mit Audacity öffnen und auch weiter bearbeiten. Auf der Homepage findet man einige Sounds z.B.

http://www.2box.se/US/pages/drumasonic/

oder

http://www.2box.se/US/pages/sample-library/

Und bei Hyperactive gibt es noch die ganzen Samples die im Auslieferungszustand auf dem Modul sind. Da sind einige gute Sounds dabei. Nicht so gut wie die aktuellen VSTIs aber sicherlich besser als man es mit Homerecording am Anfang hinbekommt.

http://www.hyperactive.de/support/2box

Gruß, Freidag (auch Linux-User)

Wäre ja noch mein Traum, mit einem Mini ITX ausreichend 'RAM zur Verfügung zu haben und auf Linux dann Toontrack und Konsorten zum laufen zu bekommen. Leider finde ich LINUX noch recht umständlich, benötigte Treiber herunterladen und dann zu hofen, das ein DAU diese auch isntallieren kann. Bis dahin muss ich wohl oder übel auf nen alten Server mit massig RAM bauen und WINDOOF einsetzen.

Zitat

So, als letztes Detail hab ich jetzt noch mal die Schaltung an den Multiplexern in die Schaltpläne rein editiert. Alle analogen Outputs laufen darüber, AUSSER Head/Bow von Snare und Ride (die ja sowieso schon eine Sonderbehandlung bekommen).

Nette Sache, die Schaltpläne sind bald soweit, dass wir nur noch die Elektronik-Kiste raskramen müssen, und schon können wir unser eigenes TD12 nachbauen .

Wäre tatsächlich mal wert nachzubauen, einfach um zu checken, ob wir mit dem analogen Signal, ähnliche Triggerergebnisse erzielen können wie das Roland TD12.
Ich würde das mal machen, wenn wieder das Geld über ist, für ein ODROID X2(Hat 4-Channel 12 bit ADC mit 1MSPS, also vermutlich ausreichend). Da muss man zwar ein wenig noch die Spannung anpassen(auf max 1.8V) aber das sollte ich noch irgendwie mit meinen E-technik-"Kenntnissen" gebacken kriegen...

Interessant wird dann der DSP-Teil...

Zitat

An den Adressleitungen zu den Multiplexern konnte man noch nachmessen, dass sie alle 0,1ms zwischen den Kanälen umschalten. Da es 4fach-Multiplexer sind, landet man also alle 0,4ms wieder am selben Kanal, das würde eine Samplingrate von 2,5kHz erlauben. Bei Snare und Ride, die nicht über Multiplexer laufen, könnte man dann eine Samplingrate von 10kHz vermuten.

Interessant, und gar nicht so schnell. Da kommt ja ein recht stufiges Signal heraus, wenn man das mit deinen Grafiken vergleicht(0,5ms Gitter). Also viel DSP kann dann intern wohl nicht mehr passieren...

Zitat

wobei Patente ja quasi eine gewisse Offenlegung voraussetzen, dafür dann aber eben die kommerziellen Nutzungsmöglichkeiten beschränken

Stimmt eigentlich... wie wärs mit nem Patent für den Thread ;).

Freidag13,
Danke für die Verlinkungen, die könnte man wenn man Lust hat auch in das Programm einarbeiten(Samples auschneiden als seperate Dateien)
Ich muss allerdings erlicherweise sagen, dass mir die Salamander Sounds in gewisser Weise besser gefallen, da ist irgendwie mehr Leben drinnen, und ich mag diesen trockenen "Garagen"-Sound.

Bezüglich Linux und Echtzeit-Sampling:

1 Sample Buffersize bei 96khz auf einem Phenom X4 940 mit Audiophile192, sind ja "langweilig", interessant wird es doch erst mit nem Low-Power-Uralt-Netbook wie meinem MSI Wind U100(Intel Atom N270(1x1.6ghz))
mit Onboard Sound.

Ich hab das verstaubte Netbook mal hervorkgekramt, um es auf seine Herz und Nierenfunktion zu testen. Drauf läuft Arch linux mit 32 bit(mehr geht nicht mit dem Atom), selbstkompilierter RT-Kernel und die eDrummer Software von "jeffg". Mit dem governor "performance", schafft man auch hier 4 Sample Buffersize pro Channel bei 48khz (bei Stereo: theoretisch 0.166ms Latenz). Fast ohne Knacken, oder ähnlichen Nebengeräuschen.
Mit einem Terrasonic Midi One USB Interface, hab ich dann knapp gemessene 5.5ms Gesamtlatenz geschafft .
Also mehr als ausreichend, und die Idee mit dem Odroid X2 ein Gesamtsystem zu schaffen(wie ein Drummodul mit echten Samples), ist dadurch noch ein Stück näher gerückt.

Übrigens die oben genannte Software kommt mit dem Salamander Kit schon fast an EZdrummer ran. Der Entwickler ist eifrig am verbessern. Ich denke er wäre dankbar wenn man noch ein paar Tips, gefundene Bugs etc. beisteuern würde.
Hier noch mal der Thread:
http://www.linuxmusicians.com/viewtopic.php?f=24&t=11024

Gruß
Philipp