Forum: FPGA, VHDL & Co. Drum-Computer in VHDL


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Ich habe meine Musikworkstation angepackt und will es um ein Schlagzeug 
erweitern. Momentan fahre ich Tests, was ich mit einem Rauschgenerator 
erreichen kann. Bisher bin ich da noch nicht so weit gekommen. Nun habe 
ich testweise jedem Kanal einen eigenen Equalizer spendiert und mir 
einen Bass, ein Becken und eine (sind wir mal gutmütig) "snare" 
hingemixt.

Es handelt sich um eine klassische Spur mit Betonung auf dem dritten 
Schlag (xxXx.xxXx) und Bass Drum auf der ersten Spur. Aus der zweiten 
und dritten Spur werden Echos abgeleitet, die zum Takt passen 2/3 und 
3/4. Das soll der Arpeggiator tun, derzeit läuft es über 
Audioverzögerung. Dann werden die Spuren ein wenig durch panning gewegt 
und zusammengemischt.

Der Rauschgenerator ist der zweistufige aus meinem Artikel, die 
Stereoeffekte werden mit neben Pegelunterschied vor allem mit 
Phasenverschiebungen erzielt, was sich allerdings im MP3 wie gehabt als 
"Gesäusel" niederschlägt..-(

Das File war klanglich noch etwas dünn, daher wurde es noch mit einem 
dynamischen EQ/Kompressor bearbeitet.

Bin auf Kommentare gespannt!

Als nächstes mal müssen die Stimmen verbessert werden. Ich brauche mehr 
tonale Anteile. Von der Architektur ist das kein Problem, ich habe ja 
1024 Stimmen und kann mehrere auf einen "Midi"-Kanal hängen. Das Problem 
ist aber das Mischen und die Erzeugung der Hüllkurven.

Mal schauen, ob ich das in verkleinerter Form in einen FPGA bekomme, 
dann liesse sich ein Projekt draus machen.

von A. S. (rava)


Bewertung
1 lesenswert
nicht lesenswert
ich find's ziemlich beeindruckend, was da rausgekommen ist. Auch wenn 
man natürlich berücksichtigen muss, dass der nachgeschaltete Kompressor 
nochmal gut "Fettigkeit" zum Sound dazu gibt.

Leider ist Instrumentenmodelling ein ziemlich anspruchsvolles Thema. Ich 
mein für den Elektroniker in mir hat das was du ablieferst einen 
wow-Effekt. In der Praxis setz ich mich aber doch wieder an eine große 
Sample Library... :)

Das hängt aber sicher von der Arbeitsweise ab und davon, auf welche 
sounds man steht bzw. welche musik man macht.
Die Hihat ist jedenfalls amtlich, was daran liegt, dass da eigentlich 
jeder den klang nur as noise + filter + hüllkurve erzeugt.
Für eine Snare braucht es in der Theorie auch nicht viel. Ein kurzer 
Impuls genügt, wenn man eine schöne Hallfahne dahinter packt.
Zur basedrum kann ich nicht viel sagen da ich die auf meinem müden 
Notebook gerade nicht gehört habe :)

von Jürgen S. (engineer) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Danke :-) Der Kompressor hatte allerdings nur die Funktion, die Stimmen 
etwas hinzubiegen, weil ich das im FPGA so noch nicht machen kann. Da 
muss dann ins Arrangement ein Lautstärkeverlauf und die EQs besser 
angepasst werden. Dummerweise passt die Master/Mixer- und die 
Effektsection nicht zusammen ins FPGA. Derzeit habe ich noch keine 
Plattform, wo alles zusammem mit dem Notengenerator hineingeht.

> Hallfahne dahinter packt
Dazu brauche ich den Reverb und der braucht auch wieder Platz :-)

von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Und siehe: Einige Equalizer und Hüllkurven später kommt dies bei raus:-)

Die Schlagzeuge haben jetzt alle einen eigenen Rauschgenerator mit 
eigener Formel und Abtasttung.

Die Snare und Hihat bestehen aus abfallendem, weissen Rauschen mit 
betonendem EQ bei ca 600-900Hz, bzw. einem schwachen Hochpass oberhalb 
1kHz, gebaut als (1-Tiefpass). Die EQs sind einfach IIR-Filter.

Die Bass Drum erzeuge ich aus einem hart gegateten, abfallender Sinus 
(einfach bei 90 Grad gestartet), dem mit einem TP ab 2kHz die Höhen 
genommen werden, damit es nur knackt, aber nicht mehr klickt. Zusätzlich 
sind Frequenzen um 500-1kHz angehoben.

Ähnlich baue ich die tonale bass line:  3 Töne als Parabel-Sinus, mit 
quadratischem Abfall und Anschnitt bei 90 Grad, um einen Knack zu 
erzeugen. Bevor diesmal mit EQs geglättet wird, übersteuere ich die 
gesamte Kurve noch um 4-5dB, damit in den ersten 100-200 ms die Spitzen 
abgeshcnitten werden und ein aggressiver Obertonanteil entsteht, der 
dann schnell verklingt. Der wird mit EQs noch zurechtgebogen und 
bandlimitiert.

Die Dynamik in der Mischung ("gallopierender" Rythmus) kommt wieder 
durch wechselnde Echos bei 600ms/300ms sowie 400ms/250ms, was zum Tempo 
passt (200ms je Teilnote). Dadurch entstehen die rythmischen 
Lautstärkeänderungen. Ich war selbst überrascht, wie lustig das 
teilweise klingt - um ehrlich zu sein, sind die 250ms ein 
Zufallstreffer, weil ich einmal falsch umgerechnet hatte :-)

Die hellen Töne am Ende sollten Kuhglocken werden, sind aber noch zu 
verrauscht - der EQ ist noch nicht schmalbandig genug. Daher hört es 
sich etwas sphärisch an. Unerklärlicherweise passen sie klanglich nicht 
zur bass line, obwohl der EQ in den Parametern stimmt. Da ist noch was 
faul.

Hinten, wo sie scheinbar im Hall versinken, hört man ein 2fach 
iteratives Echo: Der Ausgang des Echo-Generatos dieses Zweiges wird 
einmal auf den Eingang rückgelooped.

Ich denke, ich werde mich noch etwas mehr um den Echo-Generator kümmern:

Einerseits produziert er ein Super Echo, das schon einen einfachen Hall 
abgibt und generiert viel Leben im Mix, andererseits führt er schnell 
zum Phasing, weil die Wellen alle "klinisch perfekt" sind und sich 
teilweise auslöschen. Beim Übergang vom Schlagzeug mit Einmalecho zum 
Zweig mit Doppelecho bei 29sec musste ich hart umsteuern und den ersten 
stimm schalten, weil es sonst extrem "matscht".

Ich höre im Mix auch zunehmend mehr "Räumlichkeit". Ich denke, dass das 
an Mustern liegt, die der Rauschgenerator liefert und die irgendwie mit 
einander interferieren, wodurch rythmische Lautstärkeänderungen im 
ms-Bereich entstehen, die das Gehör als Echo / Raum wahrnimmt.

Gfs bekomme ich es hin, die Echos so zu trimmen, dass genau die 
gewünschte Hallfahne für die Snare entsteht. Auch die Becken müssten 
damit zu verbesern sein. Am Pult habe ich es schon Hinbekommen: Sehr 
kurze Echos machen den Klang, wie bekannt, metallisch.

Mal schauen ...

von Mirco (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> andererseits führt er schnell
> zum Phasing, weil die Wellen alle "klinisch perfekt" sind und sich
> teilweise auslöschen.
Du musst die Reflexionen ungeordnet kommen lassen, sonst werden sie 
immer mit dem Original interferieren und seltsame Seiteffekte bilden.

A. S. schrieb:
> In der Praxis setz ich mich aber doch wieder an eine große
> Sample Library... :)
Wie wäre es mit wave table synthese? Kleine Samples ins FPGA laden, um 
sie abzuspielen, sollte zu schaffen sein.

von hobbybastelnder (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Coole Sache!!!

von K. L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hast Du noch mehr Sounds/Infos dazu?
Mich interessiert, wie Du das genau machst.

von Jürgen S. (engineer) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Mirco schrieb:

> Wie wäre es mit wave table synthese?
> Kleine Samples ins FPGA laden, um
> sie abzuspielen, sollte zu schaffen sein.

Ich verwende in manchen Versionen eine Sinustabelle für die Erzeugung 
eines sehr präzisen Sinuswertes von 18Bit und besser. In das dazu 
instanziierte RAM / das externe RAM kann alles reingeladen werden. 
Allerdings ist es ein generelles Manko der WTS, dass sie nur für die 
Grundwelle richtig funktioniert, soweit eben eine DDS mit all ihren 
Problemen funktionieren kann. Technisch bedingt, sind die in der Wave 
Table eingebauten Oberwellen in der Phase immer fest an die Grundwelle 
geknüpft und der Phasensprung, der bei nicht ganzzahligen Wellen 
zwangsläufig auftritt, führt zu Brüchen bei allen Frequenzen und den 
bekannten blechernen Klängen. Diese sind erstens musikalisch nur 
begrenzt nutzbar und zweitens ja hinlänglich realisiert:

Die klassischen Rompler (ROM-basierten) Keyboards weichen dem Problem 
dadurch aus, indem sie mehr RAM implementieren, die Samples einfach 
verlängern und somit weniger Loops produzieren oder diese 
unkorrellier(er) einsetzen.

Sampler wiederum, die das auch und sehr ordentlich können, wie z.B. mein 
AKAI (Gott habe ihn seelig :-) oder seine Freunde von Roland oder E-mu 
gibt es bei EBAY für kleines Geld. Sowas brauche ich nicht zu bauen. 
Ausserdem würde ich das dann eher als Softsyth ausführen.

Ich gehe da einen anderen Weg: Ich bereitstelle pro Klang mehrere 
Oszillatoren, die ihrerseits mehrere parametrische Oberwellen generieren 
und in der Hüllkurve einzeln veränderbar sind. Damit ist der 
Oberwellenklang für jeden OSC atonal und unkorreliert einstellbar und 
produziert keinen Loop, da er keinen Anfang und kein Ende hat. Der 
Tonverlauf ist komplett kontinuierlich und die einzelnen Klanganteile 
wachsen und verlöschen in natürlicher Weise. Das ist zehnmal 
organischer, als jedes statische Sample, so super es auch eingespielt 
und aufbereitet sein sollte.

von rudi aus dem garten... (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen Schuhmacher schrieb:

> Mal schauen, ob ich das in verkleinerter Form in einen FPGA bekomme,
> dann liesse sich ein Projekt draus machen.


2010...wie weit ist das Projekt?
..

Gruss

rudi
;-)

von rudi aus dem garten... (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen Schuhmacher schrieb:
> Mirco schrieb:
>
> Ich gehe da einen anderen Weg: Ich bereitstelle pro Klang mehrere
> Oszillatoren, die ihrerseits mehrere parametrische Oberwellen generieren
> und in der Hüllkurve einzeln veränderbar sind. Damit ist der
> Oberwellenklang für jeden OSC atonal und unkorreliert einstellbar und
> produziert keinen Loop, da er keinen Anfang und kein Ende hat. Der
> Tonverlauf ist komplett kontinuierlich und die einzelnen Klanganteile
> wachsen und verlöschen in natürlicher Weise. Das ist zehnmal
> organischer, als jedes statische Sample, so super es auch eingespielt
> und aufbereitet sein sollte.



...meine es ernst - wie weit ist das Projekt Jürgen...
Du gehst eigene Wege ( klingt gut die Beschreibung! )
... ich gehe auch eigene...
wir sollten uns mal zusammentun ;-)..

Gruss

Rudi

;-)

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Schick ihm doch eine PN. Oder probiers über linkedin:
http://de.linkedin.com/in/hardwareengineer

von Matlabber (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Jürgen Schuhmacher schrieb:
> Ich gehe da einen anderen Weg: Ich bereitstelle pro Klang mehrere
> Oszillatoren, die ihrerseits mehrere parametrische Oberwellen generieren
> und in der Hüllkurve einzeln veränderbar sind. Damit ist der
> Oberwellenklang für jeden OSC atonal und unkorreliert einstellbar
Und das ist wirklich etwas Neues?
Wie machen das denn die aktuellen Drumboxen bzw die analogen von Roland 
und so weiter?

Wofür man einen FPGA braucht, um eine langsame Applikation wie einen 
Drum-Computer (Audio!) zu realisieren, wissen wohl nur eingefleischten 
digitalen Musiker.

von EMV (Gast)


Bewertung
0 lesenswert
nicht lesenswert
machs erstmal besser...

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Matlabber schrieb:
> Und das ist wirklich etwas Neues?
Zeig mir was Ähnliches. Neben den beschriebenen Funktionen an sich 
steckt allein durch die hohe Bandbreite eine Qualität im Signal, die 
üblicherweise nur von Analoginstrumenten erzielt werden kann, bei 
besseren S/N Werten.

> Wie machen das denn die aktuellen Drumboxen
Per Microcontroller, DSP und Software.

> bzw die analogen von Roland und so weiter?
Die analogen, die Du meinst (analog ist hier primär die Klangerzeugung) 
machen es echt analog mit den bekannten Restriktionen in Sachen 
Signalgüte.

> Wofür man einen FPGA braucht, um eine langsame Applikation wie einen
> Drum-Computer (Audio!) zu realisieren, wissen wohl nur eingefleischten
> digitalen Musiker.
Ein Kanal hat 192kHz -> 512 Kanäle = 100 MHz.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
rudi aus dem garten... schrieb:
> wie weit ist das Projekt?
Die Hardware ist im Bau und was die FW angeht, fehlt noch die Controlbox 
für die MIDI-Erzeugung. Das kommt, wenn ich mal wieder Zeit habe.

von Rolf S. (audiorolf)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen Schuhmacher schrieb:
> die Controlbox für die MIDI-Erzeugung
Machst Du die in hardware oder in software also mit softcore?

von R. W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen Schuhmacher schrieb:
> rudi aus dem garten... schrieb:
>> wie weit ist das Projekt?
> Die Hardware ist im Bau und was die FW angeht, fehlt noch die Controlbox
> für die MIDI-Erzeugung. Das kommt, wenn ich mal wieder Zeit habe.

So jetzt hab ich den Thrad endlich wieder gefunden.
Man sollte immer angemeldet schreiben.
Sorry Jürgen für die Verspätung.

Die Controllbox - wie stellst Du Dir das in etwa ( grob ) vor
ich meine jetzt konkret "Midi Erzeugung"...reichen Dir da 3 Byte?
btw: Denkst Du auch an Sysexen?
LG
Rudi
;-)

Und
Frohes Osterfest!

..und jetzt schalt ich die eMail Benachrichtigung ein. ;-)

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Rolf S. schrieb:
> Jürgen Schuhmacher schrieb:
>> die Controlbox für die MIDI-Erzeugung
> Machst Du die in hardware oder in software also mit softcore?
Bisher alles VHDL mit starrer Kopplung von MIDI-Kanal und Sound-Kanal.

R. W. schrieb:

> Die Controllbox - wie stellst Du Dir das in etwa ( grob ) vor
> ich meine jetzt konkret "Midi Erzeugung"...reichen Dir da 3 Byte?
> btw: Denkst Du auch an Sysexen?

Die Control-Box, also der Ton-Muster-Erzeuger, wird eine Abwandlung 
meiner MIDI-Box - dem Prinzip nach einfach ein Sequenzer. Die 
Tongeneration ist wie bei Drum-Boxen von der zeitlichen Abfolge her 
recht grob, dafür präzise, von daher gibt es keine Anforderungen für 
eine zeitlich hochaufgelöstestes MIDI, dennoch muss ich aber irgendwie 
auf mein Protokoll übersetzen und das läuft auf 5 Byte / 96kHz x 64 
S/PDIF.

: Bearbeitet durch User
von R. W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen Schuhmacher schrieb:
> Die Control-Box, also der Ton-Muster-Erzeuger, wird eine Abwandlung
> meiner MIDI-Box - dem Prinzip nach einfach ein Sequenzer. Die
> Tongeneration ist wie bei Drum-Boxen von der zeitlichen Abfolge her
> recht grob, dafür präzise, von daher gibt es keine Anforderungen für
> eine zeitlich hochaufgelöstestes MIDI, dennoch muss ich aber irgendwie
> auf mein Protokoll übersetzen und das läuft auf 5 Byte / 96kHz x 64
> S/PDIF.

Danke Jürgen, denke jetzt hab ich es verstanden aber ich frage noch mal 
nach, damit es richtig klar ist...

Du brauchst also ... sagen wir mal
Du hast potis  schalter  taster  an einem Bedienerpult mit der Du Dein 
TonSignal ( 5 Byte / 96kHz x64 S/PDIF )  dann z.b. mit  Sägezahn.. oder 
Delay.. oder Rauschen... usw
von dort aus "commandieren" / "zusammenstellen" / "kreiren"  kannst?..

Würde Dir das reichen ( Midi ist eigentlich 32 Byte so Wiki / Midi org 
und der rest wird mit Nullen gefüllt also nur zu .. ;-) ) wenn Du mit 
dem Poti einen Value von ( 5 Byte... ( Status, D1, D2, Dein4.tes , 
Dein5.tes )
Du hättest 0..255 und nochmal 0.255 in einem Packet , reicht Dir das?
Oder hab ich das völlig daneben verstanden?

Würd mich freuen...

LG
Rudi
;-)
Frohe Ostern!


email benachrichtigung klappt jetzt.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wo die Control Daten herkommen, ist ja egal. Einerseits kommt es von 
einer PC-GUI und andererseits als Alternative von einem MIDI-Controller. 
Steuern liesse sich das mit jedem MIDI-Controller, man muss nur das 
Protokoll intern übersetzen. Umgekehrt lässt sich das natürlich auch 
ausgeben, bei Nutzung des Standard MIDI eben mit reduzierter Auflösung 
und Bandbreite.

http://www.96khz.org/images/MIDI-enhanced-protocol.gif

Derzeit sieht es so aus, als ob ich mit statischem MIDI-Routing 
auskommen muss, der Grösse des Ziel-FPGAs wegen und daher wird die 
MIDI-MIX-Matrix überbrückt und fest verdrahtet. Daher wird das schwer, 
was einzuschleifen oder rauszuziehen.

von K. L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Eigentlich müsste es doch aber möglich sein, das mit USB zu machen. Das 
ist schnell genug. Muss eben der PC die Daten schon richtig bringen.

Eine andere Frage: Wie werden die Klangdaten erzeugt? Ist das eine 
analoge Nachbildung?

von Henk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo, ist möglich, dass das VHDL wird publiziert für die FPGA? Ich bin 
auch in Musik und habe Interessen für den Projekt. Kann man laden den 
Code VHDL auch in einen andere FPGA?

von Jürgen S. (engineer) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Henk schrieb:
> Hallo, ist möglich, dass das VHDL wird publiziert für die FPGA?
Aus verschiedenen Gründen werde ich den VHDL Code nicht veröffentlichen, 
aber gfs mache ich eine ladbare Version für eines der Demo Kits, z.B. 
das Spartan 6 Board von Xilinx. Aber:

Es braucht in jedem Fall noch eigene Hardware, um das zu nutzen, weil 
keines der Boards S/DIF-Ausgang hat. Denkbar wäre nur Analog oder PWM, 
wie bei der VPLD-Orgel.

von Martin K. (mkmannheim) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Wie wäre es mit i2s? Dafür gibt es Platinen mit Wandlern von 
preisgünstig bis teuer.

von K. L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Aha, hier tut sich ja mal wieder was.

Ich würde nochmal meine Frage wiederholen, wo die Klänge herkommen. 
Samples oder erzeugt?

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Alles generisch erzeugt. Daher der Begriff "Synthesizer". Samples nutzt 
man bekanntlich in "ROM"plern. Diese haben das Problem, dass das Loopen 
unangenehme und unkontrollierbare Artefakte erzeugt.

von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Kleines update: Der Drummix in der zweiten Version mit Drum Arpeggios.

Hier gibt es noch eine anderes Beispiel mit synthy base pattern:

Beitrag "Re: DSPIC-Synth - Klangbeispiel"

von Meety (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klingt nicht übel. Wo siehst Du denn die Vorteile, einen FPGA zu 
benutzen? Ich meine, es gibt doch SW-Computer genug. Ich habe da füher 
mit Fruity Loops und Rebirth gewerkelt. Die sind jetzt vielleicht 
outdatet, weil Windows XP, aber klanglich waren die doch schon echt gut.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Die Vorteile liegen auf der Hand:

1) Während Rebirth und andere aufgrund technischen Veraltens sterben, 
weil man sie nicht aufbohren kann oder sie nicht zum OS passen, kann man 
das FPGA leicht anpassen und skalieren

2) Genrell bekommt man nur mit FPGAs Abtastraten hin, die es getatten, 
Frequenzen weitgehend artefaktfrei auf jede beliebige Frequenz 
anzupassen und gut genug zu filtern, dass es den Namen "analog" verdient

3) Eigene Strukturen! Einen käuflichen drum computer haben Viele und 
solche in Software nazu jeder! Eine eigene HW produziert Klänge, die 
sonst keiner hat.

von Rolf S. (audiorolf)


Bewertung
0 lesenswert
nicht lesenswert
Die meisten Drum Computer (auch die in Software) sind doch 
manipulierbar. Selbst die TB-clones lassen es zu, die Töne komplett zu 
verdrehen.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Rolf S. schrieb:
> Die meisten Drum Computer (auch die in Software) sind doch
> manipulierbar. Selbst die TB-clones lassen es zu, die Töne komplett zu
> verdrehen.
In gewissen Grenzen, sagen wir mal. Ich weiß was die TBs können. Habe 
hier eine rumstehen. :-)

Meety schrieb:
> Klingt nicht übel. Wo siehst Du denn die Vorteile, einen FPGA zu
> benutzen? Ich meine, es gibt doch SW-Computer genug.
Hängt von der Klangtreue ab. Kanalzahl x Abtastrate x Komplexität sind 
beim FPGA um Faktor 30..50 höher, als bei einer voll ausgelasteten 
I7-CPU.

Dann haben wir noch die Echtzeitthematik. Meinen Drummix könnte man auch 
per Audio-to-MIDI in Echtzeit mit Gitarren ansteuern. 
Softwaresynthesizer sind da träge, besonders in Windows. Außerdem wirkt 
bei mehreren Kanälen wieder eine MIDI-limit.

Der Drum Computer ist inzwischen auch gewachsen und arbeitet mit dem 
Sequenzerteil direkt auf eine erweiterte Synthesengine in der P2-Version 
mit 64 Kanälen x 8 Instrumenten pro Modul. Damit sind alle Töne per 
Anschlag exakt stimmbar und zwar mit der aus der Analogtechnik bekannten 
Frequenzvorgabe. Den Rest machen die Echos:

http://96khz.org/files/2017/artixdcdemo1.wma

Am Ende sollen 2 x 16 Spuren rein für Drums + Melodie. Im Gegensatz zu 
den klassischen Funktionen wie es sie auch beim RB gab kann man meine 
Echos voll variabel kontrollieren. Vor allem können sie auch auch einen 
echten 6/8-Takt und dies mit MIDI-Auflösung von 1024 statt nur nur 96 
Takten je Beat.

von Carlo (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Genrell bekommt man nur mit FPGAs Abtastraten hin, die es getatten,
> Frequenzen weitgehend artefaktfrei auf jede beliebige Frequenz
> anzupassen

Welche Abtastraten brauchen Audiophile denn fürs Audio? Reichen die 
192kHz nicht? Wie schaffen das die Softwaregeneratoren und 
Klangprozessoren in den Soundprogrammen? Die haben nur einen I7 mit 
4GHz, der für alles reichen muss. Inklusive Umrechnung auf andere 
Frequenzen.

> und gut genug zu filtern, dass es den Namen "analog" verdient
Ab wann, ist ein Signal den analog? Das ist es nur, wenn es eine direkt 
Verbindung zwischen erzeugender und erzeugter Information gibt. Sobald 
eine diskrete Abtastung dazwischen ist, ist nichts mehr analog.

https://de.wikipedia.org/wiki/Analogsignal

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Carlo schrieb:
> Welche Abtastraten brauchen Audiophile denn fürs Audio? Reichen die
> 192kHz nicht?
Das Thema hatten wir an andere Stelle schon: Solange man eine 
generische, analytische Funktion hat, die für jeden Zeitpunkt ein 
exaktes Y(t) liefert, reichen 48kHz im Grunde aus. Mit Blick auf das 
Thema AA-Filter am Ausgang 96k. Viele Funktionen, die z.B. einen 
Energiespeicher besitzen, nichtlineare Magnetik verwenden oder 
selbstschwingende Oszillatoren haben, bzw. gar mit iterativen Methoden 
arbeiten, müssen mit entsprechender Überabtastung gefahren werden, damit 
die numerische Berechnung gelingt.


> Wie schaffen das die Softwaregeneratoren und
> Klangprozessoren in den Soundprogrammen? Die haben nur einen I7 mit
> 4GHz, der für alles reichen muss.

Alles eine Platz- und Mengenfrage. Ich habe zu diesen Vergleichen schon 
mehrfach Detailliertes verfasst und widerhole es mal anhand einer 
einfachen Betrachtung:

Wenn Ich in einem kleinen Artix 100 die RAMs weitgehend auslaste und sie 
durchschnittlich mit 3 Anschlüssen betreibe habe Ich schon durch die 
RAMs eine IO-Leistung von 2500 Gbps. Beim 200er ist es das Dreifache.
Möchte man Dasselbe mit einem Intel-Prozessor tun und hat ähnlichen 
Platz- und Speicherbedarf, dann schafft man mit einem DDR3-Controller 
maximal 100 Gbps und damit weniger als 3%. Für den Realbetrieb gegen den 
200er kommt man schnell auf einen Faktor 100.

Füllt man dann die LUTs mit Rechenarchitektur und RAM-Registern, liegt 
der Bedarf zur Emulation der Speicherzugriffe bei einem zusätzlichen 
Faktor 100!  Praktisch wird man die Berechnungen in einer CPU natürlich 
sequenziell ausführen und sich die Hälfte der Speicherzugriffe sparen, 
aber auch diese Rechnung liefert eine massive Diskrepanz zwischen FPGA 
und Prozessor:

Summiere Ich z.B. alle Speicher in meinem Synth, komme Ich auf 250kb an 
RAM-Zellen, die zugriffen und geschrieben werden müssen.
Rechnet man einen Rechenschritt für die mathematische Operation und eine 
für das Wegspeichern, dann braucht es ohne Verwaltung eine Datenrate von 
an die 100Tbps. Selbst mit 16 Kernen packt ein I7 bei 4GHz davon auch 
wieder nur 1%. Real arbeite Ich mit unterschiedlichen Variablenbreiten, 
die die 64 Bit nicht gut auslasten, verwendet Querzugriffe über mehrere 
pipeline-Stufen, was Mehrfachzugriffe erfordern würde und eine CPU muss 
auch noch Verwalten und eben die Speicherzugriffe von oben leisten.

Real kann man bei solchen Anwendungen von einem Verhältnis vom 
mindestens Faktor 200 ausgehen.


> Ab wann, ist ein Signal den analog?

Das ist wiederum eine Interpretationsfrage. Für mich ist ein System dann 
quasi analog, wenn man zwischen dem analogen und dem digitalen für die 
jeweiligen Anwendung keine Diskrepanzen mehr wahrnehmen kann.
Für die Frage der Umsetzung in MIDI und Audio sehe Ich das Thema Latenz. 
Eine geringere Abtastrate braucht indirekt immer mehr Filterlänge, um 
genau zu sein, als eine hohe Abtasrate. Praktisch alle Filter, die im 
Bereich Audio zur Anwendung kommen, haben immer ein gewisses 
Interpolationsverhalten und dort schlägt sich die Abtastrate nieder.
Wenn man mit Bezug auf das o.g. ("Überabtastung") z.B. Filterparameter 
oder Klangerzeugungsparameter iun Echtzeit ändern möchte, ist die 
Auswirkung dann analog, wenn es sich praktisch augenblicklich, also beim 
nächsten Sample auswirkt.

Auf dem Weg von MIDI zum Erzeugungsalgorithmus hat man aber etliche 
Filter in der Kette, sie es fürs MIDI-smooting, Vibrato, Modulation, etc 
und an jeder Stelle schlagen die genannten Verzögerungen zu.

von von de Kölsche Jong (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kann man den irgendwo kaufen oder nachbauen?

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
War mal geplant. Was möchtest du denn ausgeben?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.