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.
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 :)
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 :-)
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 ...
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.
Hast Du noch mehr Sounds/Infos dazu? Mich interessiert, wie Du das genau machst.
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.
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 ;-)
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 ;-)
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.
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.
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.
Jürgen Schuhmacher schrieb: > die Controlbox für die MIDI-Erzeugung Machst Du die in hardware oder in software also mit softcore?
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. ;-)
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
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.
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.
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?
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?
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.
Wie wäre es mit i2s? Dafür gibt es Platinen mit Wandlern von preisgünstig bis teuer.
Aha, hier tut sich ja mal wieder was. Ich würde nochmal meine Frage wiederholen, wo die Klänge herkommen. Samples oder erzeugt?
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.
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"
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.
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.
Die meisten Drum Computer (auch die in Software) sind doch manipulierbar. Selbst die TB-clones lassen es zu, die Töne komplett zu verdrehen.
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.
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
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.